Re: coreutils-5.1.3 released: bug-fix-only, candidate for stable 5.2.0

[Jim Meyering]

address@hidden (Michael Elizabeth Chastain) wrote:
> I tried coreutils 5.1.3 on hppa2.0w-hp-hpux11.11 and alphaev68-dec-osf5.1.
> I ran into several problems, documented below.

Thank you for taking the time to do all that.

> I had several problems using the vendor version of 'make'.  How about
> documenting that building coreutils requires gnu make on these systems?
> Either that, or you have some Makefile hacking to do.
>
> BTw, you can get accounts on these systems -- http://www.testdrive.hp.com .

I too use them.
But not as often as I would if they were more conveniently accessible.

> hppa2.0w-hp-hpux11.11, hp make CUP11.11_BL2002_1008_3 PATCH_11.11 HPC0_27755,
> hp ansi c B.11.11.28706.GP
>
>   build hangs here:
>
>     Making all in uniq
>     No suffix list.
>     Making all in wc
>     No suffix list.
>           rm -f 
> /house/chastain/coreutils/coreutils-5.1.3/tests/wc/Makefile.am /ho
>     use/chastain/coreutils/coreutils-5.1.3/tests/wc/Makefile.amt
>           sed -n '1,/^##test-files-begin/p'  > 
> /house/chastain/coreutils/coreutils-5.1.3/tests/wc/Makefile.amt
>
>   This is a bug in tests/wc/Makefile.in.  $< is defined only for
>   inference rules and .DEFAULT, not for explicit rules.  See:

Many of the coreutils Makefiles use that construct, and it's
ok as long as their rules rarely need to be run.
Maybe you accidentally modified tests/Makefile.am.in, wc/Test.pm,
or another dependent?  Otherwise, that rule shouldn't trigger.

> hppa2.0w-hp-hpux11.11, gnu make 3.79.1, hp ansi c B.11.11.28706.GP
>
>   configure works
>   build works
>   'make install' fails here:
>
>     make[3]: Entering directory `/house/chastain/cu-hpux-2/build/src'
>     mkdir -p -- . /house/chastain/cu-hpux-2/install/bin
>       /house/chastain/cu-hpux-2/coreutils-5.1.3/config/install-sh -c [ 
> /house/chastain/cu-hpux-2/install/bin/[
>     /bin/sh: /house/chastain/cu-hpux-2/coreutils-5.1.3/config/install-sh: 
> Execute permission denied.

That was indeed a problem.
I made it executable yesterday and added a dist-hook rule
to ensure that it's executable before creating the release tarballs.
...

>   config/install-sh is mode 644 in the tarball.
>   It needs to be mode 755.  After I changed that, 'make install' ran
>   successfully.
>
>   'make check' failed here:
>
>     make[3]: Entering directory `/house/chastain/cu-hpux-2/build/tests/touch'
>     PASS: relative
>     0a1
>     > touch: setting times of `/': Permission denied
>     FAIL: not-owner
>
>   This looks like a bug in the test script.
>
> alphaev68-dec-osf5.1, osf make, osf cc
>
>   First I tried configuring and bulding in a directory different from
>   the source directory.  That failed fast.  The entire make.out file is:
...
>     bison -y   /house/chastain/cu-osf-1/coreutils-5.1.3/lib/getdate.y
>     bison: No such file or directory

The coreutils INSTALL file says that you need a version of `make' that
supports the `VPATH' variable if you do non-srcdir builds.  I suspect
that applies in this case.

>   Then I tried configuring and building in the source directory.
>   That failed with:
>
>     sed -e '/^#/d' -e 's/@''PACKAGE''@/coreutils/g' ref-del.sin > 
> t-ref-del.sed
>     mv t-ref-del.sed ref-del.sed
>     Making all in src
>     Make: bad lock name:  chgrp chown chmod...

That's due to bin_PROGRAMS starting with `[' and to the OSF `make'
treating it differently than most make programs.  I'm not inclined
to address this right now.

> alphaev68-dec-osf5.1, gnu make 3.79.1, osf cc
>
>   configure works
>   build works
>   'make install' fails as before, because config/install-sh is mode 644.
>   after fixing that, 'make install' works fine
>
>   make check says:
>
>     make[3]: Entering directory `/house/chastain/cu-osf-3/build/tests'
>     ../../src/csplit: /: closing delimiter `/' missing
>     FAIL: csplit

I'll address this one separately.