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

[Dimitrios Apostolou]

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-***@gnu.org 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!

[Bob Friesenhahn]

Post by Dimitrios Apostolou
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?

This problem is well known and is because ksh93 as used in Solaris 11
and OSs derived from OpenSolaris (OpenIndiana, OmniOS, and some others
derived from Illumos, https://wiki.illumos.org/) are still using a
ksh93 which has this bug. There are more recent ksh93 versions
without the bug but no one has volunteered to produce a more modern
version for systems derived from Illumos since the shell is used as
part of booting the OS and is therefore some painful work to update.

There should be a way to tell ksh93 not to use the built-in 'rm'.

Bob