Thanks to the usage of unportable shell construct 'test -ef' introduced in Mark's patch http://cvs.savannah.gnu.org/viewcvs/classpath/lib/gen-classlist.sh.in?root=classpath&r1=1.19&r2=1.20
my build dies with
./gen-classlist.sh: test: unknown operator -ef
Actually I believe Solaris's shell is broken and really should not be using sh to run this shell script.
From Solaris's man page for test:
file1 -ef file2
True if file1 and file2 exist and refer to the
same file. (Not available in sh.)
See how it says not available in sh, Solaris's sh is known not to be a compliant POSIX shell at all.
And according to http://docs.hp.com/en/B2355-90046/ch24s29.html
test -ef is POSIX so that means this should not be running with Solaris's /bin/sh at all.
So how do we force a valid @SHELL@ replacement on Solaris?
lib/gen-classlist.sh.in does start with:
Dalibor, did you work around this somehow?
With the Classpath included in the latest gcc (4.1), the build breaks for both for the reason outlined above and due to use of the $(...) construct instead of backquotes (in QT_INCLUDE_DIR and JAY_INCLUDE_DIR IIRC).
Either all of these should be removed, or we should force an alternative shell on Solaris.
According to http://www.opengroup.org/onlinepubs/009695399/utilities/test.html, test -ef is not POSIX.
(In reply to comment #4)
> With the Classpath included in the latest gcc (4.1), the build
> breaks for both for the reason outlined above and due to use
> of the $(...) construct instead of backquotes (in
> QT_INCLUDE_DIR and JAY_INCLUDE_DIR IIRC).
> Either all of these should be removed, or we should force an
> alternative shell on Solaris.
The problem is somewhat complex, and Posix really doesn't help.
Solaris is Posix compliant, in that if you set your path
according to "getconf PATH", you get a Posix compliant shell.
Supposing, of course, that you find getconf in the path which
was set previously -- as far as I know, Posix doesn't specify
where it should be located. for this reason, a number of my
shell scripts start with something like:
if [ -x /bin/getconf ]
then PATH=` /bin/getconf PATH `
elif [ -x /usr/bin/getconf ]
then PATH=` /usr/bin/getconf PATH `
Which doesn't help for finding the shell to begin with:-).
Some possible solutions:
-- Program to a least common denominator of sh's -- the
original Bourne shell, in sum. This can actually work
fairly well, IF you have a large number of shell's to test
against. As far as I know, there is no documentation of
what is actually portable. (Still, ./configure seems to do
-- Add something to configure to hack the first line, searching
for sh in the path determined as above.
-- Two scripts will do the trick: the first simply sets PATH as
above, and invokes the second using "sh filename". For that
matter, this could probably be integrated into the
Use /bin/ksh, your problems will go away...
I was able to build kaffe and classpath cvs with CONFIG_SHELL=/bin/ksh
I had to launch configure with /bin/ksh.
This was on sparc-solaris8,9,10
Here a pointer: http://gcc.gnu.org/install/specific.html#x-x-solaris2
I'd prefer to see test -ef removed, or to see whatever needs to be done with such complex file system operations in a an environment that support such things transparently, i.e. perl.
What's the current status of this? I've just managed to build Classpath HEAD (soon to be 0.91) on Solaris 9 without (knowingly) doing anything unusual. In what circumstances do these problems occur?
It seems to occur in particular in situations in which Classpath's configury is executed as a sub-configure from some other top-level configure, like Kaffe's.
I've looked around a bit, and I think it should be possible to replace the test -ef invocation with a one-liner in perl, that basically exits with failure unless calling the stat function on both files does not result in the same device and inode.
A patch is available at http://article.gmane.org/gmane.comp.gcc.java.patches/12626/match=solaris+gcc+classpath+test+patch
Actually, it turns out that the patch at http://article.gmane.org/gmane.comp.gcc.java.patches/12626/match=solaris+gcc+classpath+test+patch
was OKed for check in by Tom Tromey at http://article.gmane.org/gmane.comp.gcc.patches/124653 so I think I should commit it into Classpath.
Checked in the patch from the mail on the gcj mailing list into classpath.
2006-11-26 Roger Sayle <roger <at> eyesopen.com>
Ian Lance Taylor <ian <at> airs.com>
Paolo Bonzini <bonzini <at> gnu.org>
Fixes bug #25557.
* lib/gen-classlist.sh.in: Avoid using test's -ef operator for
increased portability. Likewise, use -f instead of -e.
*** Bug 37000 has been marked as a duplicate of this bug. ***