Bug 25557 - Breaks badly on solaris9 during build
Summary: Breaks badly on solaris9 during build
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.20
: P3 major
Target Milestone: 0.93
Assignee: Dalibor Topic
URL:
Keywords:
: 37000 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-12-25 00:22 UTC by Dalibor Topic
Modified: 2008-08-06 16:41 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-11-26 22:01:32


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 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.
Comment 13 David Eisner 2008-08-06 16:41:44 UTC
*** Bug 37000 has been marked as a duplicate of this bug. ***