Re: Bug in autoconf 2.62 with old GNU awk

[Ralf Wildenhues]

[ moving from bug-autoconf ]

Hello Daniel,

* Daniel Richard G. wrote on Sat, Dec 13, 2008 at 07:46:14AM CET:
> I've encountered an Autoconf-related bug in attempting to build GNU coreutils 
> 6.12 (packaged with autoconf 2.62) on an older Tru64 system.
> 
>       % ./configure --disable-nls
>       [normal configure process output follows]
>       % gmake
>       Makefile:541: *** missing separator.  Stop.

> ----begin Makefile snippet----
> MAN = uname.1
> chroot.1      <---- line 541
[...]
> df.1
>               <---- yes, there's a blank line there
> chcon.1
[...]
> du.1
> \.1           <---- huh
> install.1
> link.1
> ln.1
> dir.1
> [several more man-page filenames and "\.1" oddities follow]
> whoami.1
> yes.1
> \.1
> base64.1
> MKDIR_P = build-aux/install-sh -c -d

> Something is apparently the matter with the @MAN@ substitution:

> ----begin config.status snippet----
> S["MAN"]="uname.1\n"\
> "chroot.1\n"\
[...]
> "df.1\n"\
> "\n"\
> "chcon.1\n"\
[...]
> "du.1\n"\
> "\\.1\n"\
> "install.1\n"\
> "link.1\n"\
> "ln.1\n"\
> ----end config.status snippet----

Thank you for the bug report.  I think this is a coreutils bug or two.
configure is working as intended in substituting a multiline value
(Autoconf supports multiline values since a couple of years), but the
configure.ac bits from coreutils somehow fail to flatten the value of
$MANS.

coreutils/configure.ac contains something like this:

  MAN=`echo "$optional_bin_progs "|sed 's/ /.1 /g;s/ $//'|tr -d '\\015\\012'`

  # Change ginstall.1 to "install.h" in $MAN.
  MAN=`for m in $MAN; do test $m = ginstall.1 && m=install.1; echo $m; done \
    | tr '\015\012' '  '; echo`

  # Remove [.1, since writing a portable rule for it in man/Makefile.am
  # is not practical.  The sed LHS below uses the autoconf quadrigraph
  # representing '['.
  MAN=`echo "$MAN"|sed 's/\@<:@\.1//'`

which should remove newlines from $MAN altogether.  There is more
munging of $optional_bin_progs earlier, and through the macros in
m4/include-exclude-prog.m4.  I don't quite see yet where this code
should fail.  Likely another 'tr' incompatibility we are not aware
of yet?  Can you try to look into this?  I cannot reproduce it on
Tru64/OSF 4.0D.  ($PATH would be interesting, too, to see which tr
you are using).

Thanks,
Ralf