Re: coreutils-6.4 build feedback

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> Now we just need to fix the autoconf check
>> not to define HAVE_FSEEKO, but that's where I stopped.
>> I have a hard time getting motivated for such crufty old systems.
>
> No sense of history?  Not even nostalgia?  :-)

Sure, both :-)
Just not enough time, and that's where I draw the line.

> I installed this into Autoconf in an attempt to fix that.  I've always
> wanted an excuse to do an if-then-else with a macro name....
>
> 2006-10-24  Paul Eggert  <address@hidden>
>
>       * lib/autoconf/specific.m4 (_AC_SYS_LARGEFILE_MACRO_VALUE):
>       If FUNCTION-BODY is nonempty, use AC_LINK_IFELSE rather than
>       AC_COMPILE_IFELSE, to work around problem with OSF/1 4.0F fseeko
>       reported by Nelson H. F. Beebe for Coreutils 6.4.

Thank you!  Using configure generated by just-updated-from-cvs autoconf,
a coreutils build and test finally completed on that crufty old system.
These failures remain:

  make[3]: Entering directory `/tmp/coreutils-6.5-cvs/tests/readlink'
  PASS: rl-1
  FAIL: can-e
  FAIL: can-f
  FAIL: can-m

Those are because of a (new-to-me) shell bug:
Note how "$p" (which should be empty) expands to "/" here:

    $ sh -xc 'p=; echo "$p"/subdir/'
    p=
    + echo //subdir/
    //subdir/

But not here, with the entire string double-quoted:

    $ sh -xc 'p=; echo "$p/subdir/"'
    p=
    + echo /subdir/
    /subdir/

You can trigger the bug also when replacing "subdir" with any string,
including the empty one:

  $ sh -xc 'p=; echo "$p"/e/'
  p=
  + echo //e/
  //e/
  $ sh -xc 'p=; echo "$p"//'
  p=
  + echo ///
  ///

For the record, running config.guess on this system reports
alphaev56-dec-osf4.0f

uname says it's Tru64 'V4.0 1229'.

Doubtless long overdue for retirement.