configure fails when PATH=/usr/xpg4/bin:/usr/bin on Solaris 11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux