Hello again,
here is the failing log of "configure" (as generated by GNU Autoconf 2.69)
when executed with altered path on Solaris 11:
$ PATH=/usr/xpg4/bin:/usr/bin /bin/sh ./configure
checking for a BSD-compatible install... config/install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... config/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... no
checking whether make supports nested variables... no
Usage: rm [-cFdfirRuv] file ...
Oops!
Your 'rm' program seems unable to run without file operands specified
on the command line, even when the '-f' option is present. This is contrary
to the behaviour of most rm programs out there, and not conforming with
the upcoming POSIX standard: <http://austingroupbugs.net/view.php?id=542>
Please tell bug-automake@xxxxxxx about your system, including the value
of your $PATH and any error possibly output before this message. This
can help us improve future automake versions.
[...]
I'm not sure if this bug belongs to automake or autoconf, but I'm
reporting this here since it seems relevant to the recent discussion.
Tracing the shell shows that "rm -f" command fails miserably under /bin/sh
when executed with an altered path, because it is a shell *built-in*
command!
Here are some manual executions that showcase this behaviour:
$ PATH=/usr/xpg4/bin:/usr/bin /bin/sh
$ type rm
rm is a shell builtin version of /usr/xpg4/bin/rm
$ rm -f
Usage: rm [-cFdfirRuv] file ...
NOTE: the message about "/usr/xpg4/bin/rm" is completely bogus as there is
no such command! Basically what it means is that it is a built-in command,
presumably of /bin/sh (the current shell).
BUT if I execute /bin/sh with the usual PATH, rm is *not a built-in* and
configure works fine!
$ PATH=/usr/bin:/usr/xpg4/bin /bin/sh
$ type rm
rm is a tracked alias for /usr/bin/rm
$ rm -f
$ echo $?
0
NOTE: this happens only on Solaris 11; on Solaris 10 /bin/sh never treats
"rm" as a built-in.
So is this something to report to automake, as a "broken rm" case? Or is
it an autoconf because the script fails to re-exec under a sane shell?
Thanks in advance,
Dimitris
P.S. Apparently playing with the PATH was not such a good idea so I'm
probably undoing this change in my build-environment. It would be nice to
resolve these issues anyhow!
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
