[Top][All Lists]

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

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

From: Dimitrios Apostolou
Subject: configure fails when PATH=/usr/xpg4/bin:/usr/bin on Solaris 11
Date: Sat, 28 Jan 2017 17:50:52 +0100 (CET)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

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 ...

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: <>

Please tell address@hidden 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 $?

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,

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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]