|Summary:||Breaks badly on solaris9 during build|
|Product:||classpath||Reporter:||Dalibor Topic <robilad>|
|Component:||classpath||Assignee:||Dalibor Topic <robilad>|
|Severity:||major||CC:||bug-classpath, deisner, james.kanze, robilad|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2006-11-26 22:01:32|
Description Dalibor Topic 2005-12-25 00:22:14 UTC
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 [snip] ./gen-classlist.sh: test: unknown operator -ef cheers, dalibor topic
Comment 1 Andrew Pinski 2005-12-31 23:57:44 UTC
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.
Comment 2 Mark Wielaard 2006-01-01 15:39:23 UTC
So how do we force a valid @SHELL@ replacement on Solaris? lib/gen-classlist.sh.in does start with: #! @SHELL@
Comment 3 Mark Wielaard 2006-02-02 13:33:41 UTC
Dalibor, did you work around this somehow?
Comment 4 Andrew John Hughes 2006-03-18 22:26:04 UTC
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.
Comment 5 James Kanze 2006-04-13 08:05:22 UTC
(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 ` else PATH=/usr/bin:/bin fi export 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 it.) -- 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 Makefiles.
Comment 6 Andreas Tobler 2006-04-13 21:48:27 UTC
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
Comment 7 Dalibor Topic 2006-04-14 23:01:35 UTC
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.
Comment 8 Andrew John Hughes 2006-04-27 15:36:49 UTC
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?
Comment 9 Dalibor Topic 2006-05-07 21:26:49 UTC
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.
Comment 10 Dalibor Topic 2006-11-26 21:52:12 UTC
Comment 11 Dalibor Topic 2006-11-26 22:01:32 UTC
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.
Comment 12 Dalibor Topic 2006-11-27 14:57:09 UTC
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.