[ 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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils