* Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
@ 2002-04-30 4:51 glebourgeois
2002-04-30 20:29 ` Alexandre Oliva
0 siblings, 1 reply; 46+ messages in thread
From: glebourgeois @ 2002-04-30 4:51 UTC (permalink / raw)
To: gcc
Machine: SunFire 6800 with Solaris 8.
config.guess output: sparc-sun-solaris2.8
BuildDir/gcc/xgcc -v output:
Using built-in specs.
Configured with: ../gcc-20020429/configure
--prefix=/softntools/tools/gcc-20020429 --enable-shared
--enable-threads=posix
Thread model: posix
gcc version 3.1 20020429 (prerelease)
Everything ran pretty well until configuring the boehm-gc which ended with
the following error:
loading cache ../config.cache within ltconfig
configure: error: libtool tag configuration failed
gmake[1]: *** [configure-target-boehm-gc] Error 1
gmake[1]: Leaving directory
`/softntools/softadm/Compilation/Build-gcc-20020429'
gmake: *** [bootstrap] Error 2
Anyone got any clue?
snapshot gcc-20020415 compiled fine, snapshot gcc-20020422 failed while
configuring Java.
I do hope gcc-3.1 release will bootstrap fine ('cause I need the gcc 64-bit
compiler!).
Gilles.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-04-30 4:51 Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8 glebourgeois
@ 2002-04-30 20:29 ` Alexandre Oliva
2002-05-01 9:25 ` Joe Buck
0 siblings, 1 reply; 46+ messages in thread
From: Alexandre Oliva @ 2002-04-30 20:29 UTC (permalink / raw)
To: glebourgeois; +Cc: gcc
On Apr 30, 2002, glebourgeois@amadeus.net wrote:
> loading cache ../config.cache within ltconfig
> configure: error: libtool tag configuration failed
> gmake[1]: *** [configure-target-boehm-gc] Error 1
> gmake[1]: Leaving directory
> `/softntools/softadm/Compilation/Build-gcc-20020429'
> gmake: *** [bootstrap] Error 2
> Anyone got any clue?
It's a bug in /bin/sh, documented in the GCC platforms-specific
installation instructions. Set CONFIG_SHELL=/bin/ksh.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-04-30 20:29 ` Alexandre Oliva
@ 2002-05-01 9:25 ` Joe Buck
2002-05-01 13:10 ` Alexandre Oliva
0 siblings, 1 reply; 46+ messages in thread
From: Joe Buck @ 2002-05-01 9:25 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: glebourgeois, gcc
> On Apr 30, 2002, glebourgeois@amadeus.net wrote:
>
> > loading cache ../config.cache within ltconfig
> > configure: error: libtool tag configuration failed
> > gmake[1]: *** [configure-target-boehm-gc] Error 1
> > gmake[1]: Leaving directory
> > `/softntools/softadm/Compilation/Build-gcc-20020429'
> > gmake: *** [bootstrap] Error 2
>
> > Anyone got any clue?
>
> It's a bug in /bin/sh, documented in the GCC platforms-specific
> installation instructions. Set CONFIG_SHELL=/bin/ksh.
As I reported yesterday, if you do this the build will get further, but
it will still fail.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 9:25 ` Joe Buck
@ 2002-05-01 13:10 ` Alexandre Oliva
2002-05-01 13:12 ` Joe Buck
0 siblings, 1 reply; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-01 13:10 UTC (permalink / raw)
To: Joe Buck; +Cc: glebourgeois, gcc
On May 1, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:
>> On Apr 30, 2002, glebourgeois@amadeus.net wrote:
>>
>> > loading cache ../config.cache within ltconfig
>> > configure: error: libtool tag configuration failed
>> > gmake[1]: *** [configure-target-boehm-gc] Error 1
>> > gmake[1]: Leaving directory
>> > `/softntools/softadm/Compilation/Build-gcc-20020429'
>> > gmake: *** [bootstrap] Error 2
>>
>> > Anyone got any clue?
>>
>> It's a bug in /bin/sh, documented in the GCC platforms-specific
>> installation instructions. Set CONFIG_SHELL=/bin/ksh.
> As I reported yesterday, if you do this the build will get further, but
> it will still fail.
It works for me, but you have to set CONFIG_SHELL=/bin/ksh before you
get the whole build started. In order to do it after you get the
failure, you have to rm -rf say sparc-sun-solaris2.8/boehm-gc, such
that it gets configured properly, otherwise you won't have that
directory or one of its multilibs configured and the build will bomb
again.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 13:10 ` Alexandre Oliva
@ 2002-05-01 13:12 ` Joe Buck
2002-05-01 13:29 ` Richard Henderson
0 siblings, 1 reply; 46+ messages in thread
From: Joe Buck @ 2002-05-01 13:12 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Joe Buck, glebourgeois, gcc
> >> It's a bug in /bin/sh, documented in the GCC platforms-specific
> >> installation instructions. Set CONFIG_SHELL=/bin/ksh.
>
> > As I reported yesterday, if you do this the build will get further, but
> > it will still fail.
>
> It works for me, but you have to set CONFIG_SHELL=/bin/ksh before you
> get the whole build started. In order to do it after you get the
> failure, you have to rm -rf say sparc-sun-solaris2.8/boehm-gc, such
> that it gets configured properly, otherwise you won't have that
> directory or one of its multilibs configured and the build will bomb
> again.
But that's what I did: I set CONFIG_SHELL to /bin/ksh after I ran
configure, and built in an empty directory.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 13:12 ` Joe Buck
@ 2002-05-01 13:29 ` Richard Henderson
2002-05-01 13:46 ` Joe Buck
2002-05-01 20:39 ` Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help) Joe Buck
0 siblings, 2 replies; 46+ messages in thread
From: Richard Henderson @ 2002-05-01 13:29 UTC (permalink / raw)
To: Joe Buck; +Cc: Alexandre Oliva, glebourgeois, gcc
On Wed, May 01, 2002 at 01:12:48PM -0700, Joe Buck wrote:
> I set CONFIG_SHELL to /bin/ksh after I ran configure...
Too late. Do
CONFIG_SHELL=/bin/ksh ksh ../src/configure [...]
r~
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 13:29 ` Richard Henderson
@ 2002-05-01 13:46 ` Joe Buck
2002-05-01 16:54 ` Alexandre Oliva
2002-05-03 4:52 ` PATCH for " Gerald Pfeifer
2002-05-01 20:39 ` Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help) Joe Buck
1 sibling, 2 replies; 46+ messages in thread
From: Joe Buck @ 2002-05-01 13:46 UTC (permalink / raw)
To: Richard Henderson; +Cc: Joe Buck, Alexandre Oliva, glebourgeois, gcc
> On Wed, May 01, 2002 at 01:12:48PM -0700, Joe Buck wrote:
> > I set CONFIG_SHELL to /bin/ksh after I ran configure...
>
> Too late. Do
>
> CONFIG_SHELL=/bin/ksh ksh ../src/configure [...]
The installation instructions should be modified if this is required.
(It appears required only for Java; the other compilers and libraries
build either way).
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 13:46 ` Joe Buck
@ 2002-05-01 16:54 ` Alexandre Oliva
2002-05-01 16:58 ` Phil Edwards
2002-05-03 4:52 ` PATCH for " Gerald Pfeifer
1 sibling, 1 reply; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-01 16:54 UTC (permalink / raw)
To: Joe Buck; +Cc: Richard Henderson, glebourgeois, gcc
On May 1, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:
>> On Wed, May 01, 2002 at 01:12:48PM -0700, Joe Buck wrote:
>> > I set CONFIG_SHELL to /bin/ksh after I ran configure...
>>
>> Too late. Do
>>
>> CONFIG_SHELL=/bin/ksh ksh ../src/configure [...]
> The installation instructions should be modified if this is required.
It is not required. The bug comes and goes at random. I haven't had
it on Solaris 2./sparc5 or 2.6/sparc for a while, but it has been
consistent on Solaris 7/sparc/x86 in the past 2-3 weeks.
> (It appears required only for Java; the other compilers and libraries
> build either way).
FWIW, I've got it in libstdc++-v3 in the past. Any time you drop all
the shell complexity of libtool into Solaris' /bin/sh, you're taking a
risk.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 16:54 ` Alexandre Oliva
@ 2002-05-01 16:58 ` Phil Edwards
2002-05-01 17:10 ` Joe Buck
2002-05-01 19:52 ` Alexandre Oliva
0 siblings, 2 replies; 46+ messages in thread
From: Phil Edwards @ 2002-05-01 16:58 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Joe Buck, Richard Henderson, gcc
On Wed, May 01, 2002 at 08:54:15PM -0300, Alexandre Oliva wrote:
> On May 1, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:
> > The installation instructions should be modified if this is required.
>
> It is not required. The bug comes and goes at random. I haven't had
How about for 3.2 we /make/ it required, and automate it in the top-level
configury? Solaris' /bin/sh has become enough of an annoyance to deserve
that, IMHO.
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 16:58 ` Phil Edwards
@ 2002-05-01 17:10 ` Joe Buck
2002-05-01 19:52 ` Alexandre Oliva
1 sibling, 0 replies; 46+ messages in thread
From: Joe Buck @ 2002-05-01 17:10 UTC (permalink / raw)
To: Phil Edwards; +Cc: Alexandre Oliva, Joe Buck, Richard Henderson, gcc
> On Wed, May 01, 2002 at 08:54:15PM -0300, Alexandre Oliva wrote:
> > On May 1, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:
> > > The installation instructions should be modified if this is required.
> >
> > It is not required. The bug comes and goes at random. I haven't had
>
> How about for 3.2 we /make/ it required, and automate it in the top-level
> configury? Solaris' /bin/sh has become enough of an annoyance to deserve
> that, IMHO.
What matters is that when we release 3.1, people who follow the directions
should wind up with a compiler.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 16:58 ` Phil Edwards
2002-05-01 17:10 ` Joe Buck
@ 2002-05-01 19:52 ` Alexandre Oliva
1 sibling, 0 replies; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-01 19:52 UTC (permalink / raw)
To: Phil Edwards; +Cc: Joe Buck, Richard Henderson, gcc
On May 1, 2002, Phil Edwards <phil@jaj.com> wrote:
> On Wed, May 01, 2002 at 08:54:15PM -0300, Alexandre Oliva wrote:
>> On May 1, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:
>> > The installation instructions should be modified if this is required.
>>
>> It is not required. The bug comes and goes at random. I haven't had
> How about for 3.2 we /make/ it required, and automate it in the top-level
> configury? Solaris' /bin/sh has become enough of an annoyance to deserve
> that, IMHO.
I've been kind of expecting that, as soon as we adopt a newer version
of libtool that doesn't use a separate ltconfig shell script, the
problem will go away.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 13:29 ` Richard Henderson
2002-05-01 13:46 ` Joe Buck
@ 2002-05-01 20:39 ` Joe Buck
2002-05-01 22:46 ` Alexandre Oliva
2002-05-01 23:11 ` Richard Henderson
1 sibling, 2 replies; 46+ messages in thread
From: Joe Buck @ 2002-05-01 20:39 UTC (permalink / raw)
To: Richard Henderson; +Cc: Joe Buck, Alexandre Oliva, glebourgeois, gcc
> On Wed, May 01, 2002 at 01:12:48PM -0700, Joe Buck wrote:
> > I set CONFIG_SHELL to /bin/ksh after I ran configure...
>
> Too late. Do
>
> CONFIG_SHELL=/bin/ksh ksh ../src/configure [...]
Richard, I have followed your instructions exactly, and I still get
a build failure. CONFIG_SHELL=/bin/ksh fixes the ltconfig crash,
but it does not fix the eventual failure that occurs when
the sparcv9/libgcj.so is built.
Simply put, libgcj does not build on sparc-sun-solaris2.7.
Here are the failing commands, same as before:
creating libgcj.la
(cd .libs && rm -f libgcj.la && ln -s ../libgcj.la libgcj.la)
/bin/ksh ./libtool --tag=GCJ --mode=link /remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/gcc/gcj -B/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava/ -B/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/gcc/ -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava -g -O2 -m64 -m64 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /u/jbuck/gcc-3.1-pre.sol2/lib/sparcv9 -shared-libgcc libgcj.la -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava/.libs
/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/gcc/gcj -B/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava/ -B/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/gcc/ -g -O2 -m64 -m64 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava ./.libs/libgcj.so -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libstdc++-v3/src -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libstdc++-v3/src/.libs -lpthread -lrt -ldl -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/gcc/sparcv9 -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/gcc -L/remote/release/1999.10-SIM/sparcOS5/gcc/gcc-2.6.3/lib/gcc-lib -L/u/jbuck/gcc-3.1-pre.sol2/lib/gcc-lib/sparc-sun-solaris2.7/3.1/sparcv9 -L/u/jbuck/gcc-3.1-pre.sol2/lib/gcc-lib/sparc-sun-solaris2.7/3.1 -L/usr/ccs/bin/sparcv9 -L/usr/ccs/bin -L/usr/ccs/lib/sparcv9 -L/usr/ccs/lib -L/u/jbuck/gcc-3.1-pre.sol2/lib/gcc-lib/sparc-sun-solaris2.7/3.1/../../../sparcv9 -L/u/jbuck/gcc-3.1-pre.sol2/lib/gcc-lib/sparc-sun-solaris2.7/3.1/../../.. -L/lib/sparcv9 -L/usr/lib/sparcv9 -lgcc_s_sparcv9 -lgcc_s_sparcv9 -L/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava/.libs -Wl,-R -Wl,/u/jbuck/gcc-3.1-pre.sol2/lib/sparcv9
ld: fatal: file /u/jbuck/gcc-3.1-pre.sol2/lib/gcc-lib/sparc-sun-solaris2.7/3.1/../../../sparcv9/libgcj.so: recording name `libgcj.so.3' matches that provided by file ./.libs/libgcj.so
ld: fatal: File processing errors. No output written to .libs/jv-convert
collect2: ld returned 1 exit status
make[5]: *** [jv-convert] Error 1
make[5]: Leaving directory `/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/sparcv9/libjava'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/libjava'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory `/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2/sparc-sun-solaris2.7/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/remote/dtg103/jbuck/gnu/src/cvs/3_1_branch/gcc.sol2'
make: *** [bootstrap-lean] Error 2
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 20:39 ` Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help) Joe Buck
@ 2002-05-01 22:46 ` Alexandre Oliva
2002-05-01 22:57 ` David S. Miller
2002-05-02 15:31 ` Joe Buck
2002-05-01 23:11 ` Richard Henderson
1 sibling, 2 replies; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-01 22:46 UTC (permalink / raw)
To: Joe Buck; +Cc: Richard Henderson, glebourgeois, gcc
On May 2, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:
> ld: fatal: file /u/jbuck/gcc-3.1-pre.sol2/lib/gcc-lib/sparc-sun-solaris2.7/3.1/../../../sparcv9/libgcj.so: recording name `libgcj.so.3' matches that provided by file ./.libs/libgcj.so
This is a different problem. It's the hideous bug in Solaris that
won't let you create a library if it finds another pre-installed
library with the same SONAME. This is even documented, and it's the
reason why libjava is (or used to be) disabled on Solaris 7 if it was
found to be previously installed.
Please look for `sparc-*-solaris2.8' in the top-level configure.in,
and replace it with:
sparc-*-solaris2.[0123456] | sparc-*-solaris2.[0123456].*) ;;
sparc*-*-solaris2.*)
the effect of this test will be to match Solaris 7 and above, and
enable the check that will warn and disable libgcj if it's found to be
already installed.
Hmm... I wonder why we've never run into this problem on Solaris 7
before. Perhaps there's some new patch for Solaris 7's ld that merged
the lossage from Solaris 8? :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 22:46 ` Alexandre Oliva
@ 2002-05-01 22:57 ` David S. Miller
2002-05-02 9:35 ` Tom Tromey
2002-05-02 12:19 ` Alexandre Oliva
2002-05-02 15:31 ` Joe Buck
1 sibling, 2 replies; 46+ messages in thread
From: David S. Miller @ 2002-05-01 22:57 UTC (permalink / raw)
To: aoliva; +Cc: Joe.Buck, rth, glebourgeois, gcc
From: Alexandre Oliva <aoliva@redhat.com>
Date: 02 May 2002 02:46:21 -0300
This is a different problem. It's the hideous bug in Solaris that
won't let you create a library if it finds another pre-installed
library with the same SONAME.
...
Hmm... I wonder why we've never run into this problem on Solaris 7
before. Perhaps there's some new patch for Solaris 7's ld that merged
the lossage from Solaris 8? :-(
For reference the most detailed posting I can find on this
issue is:
http://gcc.gnu.org/ml/java/2002-03/msg00348.html
and from what I can tell, it is intentional behavior and not a bug in
the Solaris linker. Why do we need to specify -lgcj when linking
together libgcj.so? That looks bogus...
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 20:39 ` Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help) Joe Buck
2002-05-01 22:46 ` Alexandre Oliva
@ 2002-05-01 23:11 ` Richard Henderson
2002-05-02 3:45 ` Rainer Orth
2002-05-02 7:57 ` Joe Buck
1 sibling, 2 replies; 46+ messages in thread
From: Richard Henderson @ 2002-05-01 23:11 UTC (permalink / raw)
To: Joe Buck; +Cc: Alexandre Oliva, glebourgeois, gcc
On Wed, May 01, 2002 at 08:39:42PM -0700, Joe Buck wrote:
> Simply put, libgcj does not build on sparc-sun-solaris2.7.
But java is *not* default on solaris, so at this late date
I am unconcerned.
r~
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 23:11 ` Richard Henderson
@ 2002-05-02 3:45 ` Rainer Orth
2002-05-02 8:06 ` Joe Buck
2002-05-02 9:36 ` Gerald Pfeifer
2002-05-02 7:57 ` Joe Buck
1 sibling, 2 replies; 46+ messages in thread
From: Rainer Orth @ 2002-05-02 3:45 UTC (permalink / raw)
To: Richard Henderson; +Cc: Joe Buck, Alexandre Oliva, glebourgeois, gcc
Richard Henderson <rth@redhat.com> writes:
> On Wed, May 01, 2002 at 08:39:42PM -0700, Joe Buck wrote:
> > Simply put, libgcj does not build on sparc-sun-solaris2.7.
>
> But java is *not* default on solaris, so at this late date
> I am unconcerned.
It used to be up to solaris 2.7, and disabled for 2.8 in the toplevel
configure.in. This has changed, though: now it's on by default for all
releases, with a check which bails out if libgcj.la is present in $libdir.
This check is for sparc-*-solaris2.8 only at the moment. The new reports
indicate that this problem occurs at least with some ld patchlevels on
solaris 2.7. I've just verified that it happens with the latest solaris
2.6 (107733-10) and 2.5.1 (103627-15) ld patches as well.
So the safest approach seems to be to match *-*-solaris2* there to
accomodate all of sparc, sparcv9 and i?86.
Rainer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 23:11 ` Richard Henderson
2002-05-02 3:45 ` Rainer Orth
@ 2002-05-02 7:57 ` Joe Buck
1 sibling, 0 replies; 46+ messages in thread
From: Joe Buck @ 2002-05-02 7:57 UTC (permalink / raw)
To: Richard Henderson; +Cc: Joe Buck, Alexandre Oliva, glebourgeois, gcc
> On Wed, May 01, 2002 at 08:39:42PM -0700, Joe Buck wrote:
> > Simply put, libgcj does not build on sparc-sun-solaris2.7.
>
> But java is *not* default on solaris, so at this late date
> I am unconcerned.
I don't understand this comment. I applied no special configure options,
and "make bootstrap" attempted to build Java and libgcj.
If you want it to be off by default, it seems that we need a patch to
accomplish this.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 3:45 ` Rainer Orth
@ 2002-05-02 8:06 ` Joe Buck
2002-05-02 9:36 ` Gerald Pfeifer
1 sibling, 0 replies; 46+ messages in thread
From: Joe Buck @ 2002-05-02 8:06 UTC (permalink / raw)
To: Rainer Orth
Cc: Richard Henderson, Joe Buck, Alexandre Oliva, glebourgeois, gcc
[ assertion that java is not on by default on Solaris ]
Rainer Orth writes:
> It used to be up to solaris 2.7, and disabled for 2.8 in the toplevel
> configure.in. This has changed, though: now it's on by default for all
> releases, with a check which bails out if libgcj.la is present in $libdir.
> This check is for sparc-*-solaris2.8 only at the moment. The new reports
> indicate that this problem occurs at least with some ld patchlevels on
> solaris 2.7. I've just verified that it happens with the latest solaris
> 2.6 (107733-10) and 2.5.1 (103627-15) ld patches as well.
> So the safest approach seems to be to match *-*-solaris2* there to
> accomodate all of sparc, sparcv9 and i?86.
Sounds good. The installation instructions should also be patched to
indicate that the Solaris user should remove any previously-installed libgcj
files before trying to build Java.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 22:57 ` David S. Miller
@ 2002-05-02 9:35 ` Tom Tromey
2002-05-02 12:19 ` Alexandre Oliva
1 sibling, 0 replies; 46+ messages in thread
From: Tom Tromey @ 2002-05-02 9:35 UTC (permalink / raw)
To: David S. Miller; +Cc: Joe.Buck, rth, glebourgeois, gcc
>>>>> "David" == David S Miller <davem@redhat.com> writes:
David> For reference the most detailed posting I can find on this
David> issue is:
David> http://gcc.gnu.org/ml/java/2002-03/msg00348.html
David> and from what I can tell, it is intentional behavior and not a bug in
David> the Solaris linker. Why do we need to specify -lgcj when linking
David> together libgcj.so? That looks bogus...
It doesn't happen when linking libgcj.so. It happens when linking
jv-convert or other programs in libgcj. Getting rid of the explicit
-lgcj doesn't help. There is more information on this in the
archives; look around the time that the top-level configure patch went
in. Basically I think it can't be better than it is now :-(
Tom
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 3:45 ` Rainer Orth
2002-05-02 8:06 ` Joe Buck
@ 2002-05-02 9:36 ` Gerald Pfeifer
1 sibling, 0 replies; 46+ messages in thread
From: Gerald Pfeifer @ 2002-05-02 9:36 UTC (permalink / raw)
To: Rainer Orth
Cc: Richard Henderson, Joe Buck, Alexandre Oliva, glebourgeois, gcc,
java, Tom Tromey
[ I added an explicit Cc: to Tom and the java list, as Tom has spent
most time with this "nice" bug. ]
On 2 May 2002, Rainer Orth wrote:
>> But java is *not* default on solaris, so at this late date
>> I am unconcerned.
> It used to be up to solaris 2.7, and disabled for 2.8 in the toplevel
> configure.in. This has changed, though: now it's on by default for all
> releases, with a check which bails out if libgcj.la is present in $libdir.
> This check is for sparc-*-solaris2.8 only at the moment. The new reports
> indicate that this problem occurs at least with some ld patchlevels on
> solaris 2.7. I've just verified that it happens with the latest solaris
> 2.6 (107733-10) and 2.5.1 (103627-15) ld patches as well.
>
> So the safest approach seems to be to match *-*-solaris2* there to
> accomodate all of sparc, sparcv9 and i?86.
As the one having reported the problem originally (and tried various
fixes Tom and others have suggested) I agree.
Given your new information, this seems to be the safest approach. (Can
one of you submit a patch for configure and the installation docs for
this?)
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 22:57 ` David S. Miller
2002-05-02 9:35 ` Tom Tromey
@ 2002-05-02 12:19 ` Alexandre Oliva
2002-05-02 13:37 ` Rainer Orth
2002-05-02 14:03 ` David S. Miller
1 sibling, 2 replies; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-02 12:19 UTC (permalink / raw)
To: David S. Miller; +Cc: Joe.Buck, rth, glebourgeois, gcc
On May 2, 2002, "David S. Miller" <davem@redhat.com> wrote:
> and from what I can tell, it is intentional behavior and not a bug in
> the Solaris linker.
If linking with `.libs/libgcj.so -L.libs -lgcj' fails but `-L.libs
-lgcj -lgcj' works, because the linker thinks they're two different
libraries with the same SONAME in the former case and it notices
they're the same library in the latter, it sounds like a linker bug to
me.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 12:19 ` Alexandre Oliva
@ 2002-05-02 13:37 ` Rainer Orth
2002-05-02 13:55 ` Richard Henderson
2002-05-02 14:03 ` David S. Miller
1 sibling, 1 reply; 46+ messages in thread
From: Rainer Orth @ 2002-05-02 13:37 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: David S. Miller, Joe.Buck, rth, glebourgeois, gcc
Alexandre Oliva <aoliva@redhat.com> writes:
> If linking with `.libs/libgcj.so -L.libs -lgcj' fails but `-L.libs
> -lgcj -lgcj' works, because the linker thinks they're two different
> libraries with the same SONAME in the former case and it notices
> they're the same library in the latter, it sounds like a linker bug to
> me.
but this is not what happens: the error only shows up if you have two
different files with the same SONAME, as can be seen e.g. in
http://gcc.gnu.org/ml/java/2001-04/msg00129.html
ld: fatal: file /sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.0/../../../libgcj.so: recording name `libgcj.so.2' matches that provided by file ./.libs/libgcj.so
Linking the same file twice only gets you a warning:
% gcc -o hello hello.c /usr/lib/libc.so -lc
ld: warning: file /usr/lib/libc.so: attempted multiple inclusion of file
ld: warning: file /usr/lib/libc.so: attempted multiple inclusion of file
% cp /usr/lib/libc.so .
% gcc -o hello hello.c libc.so -lc
ld: fatal: recording name conflict: file `libc.so' and file `/usr/lib/libc.so' provide identical dependency names: libc.so.1 (possible multiple inclusion of the same file)
ld: fatal: File processing errors. No output written to hello
collect2: ld returned 1 exit status
Looks correct to me.
Rainer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 13:37 ` Rainer Orth
@ 2002-05-02 13:55 ` Richard Henderson
2002-05-02 14:41 ` Rainer Orth
2002-05-02 14:46 ` David S. Miller
0 siblings, 2 replies; 46+ messages in thread
From: Richard Henderson @ 2002-05-02 13:55 UTC (permalink / raw)
To: Rainer Orth; +Cc: Alexandre Oliva, David S. Miller, Joe.Buck, glebourgeois, gcc
On Thu, May 02, 2002 at 10:37:31PM +0200, Rainer Orth wrote:
> but this is not what happens: the error only shows up if you have two
> different files with the same SONAME, as can be seen e.g. in
>
> http://gcc.gnu.org/ml/java/2001-04/msg00129.html
>
> ld: fatal: file /sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.0/../../../libgcj.so: recording name `libgcj.so.2' matches that provided by file ./.libs/libgcj.so
But what prompted it to go looking in /sw/test/ in the first place?
The -L option should have directed the search for -lgcj to ./.libs/.
r~
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 12:19 ` Alexandre Oliva
2002-05-02 13:37 ` Rainer Orth
@ 2002-05-02 14:03 ` David S. Miller
2002-05-02 14:06 ` Richard Henderson
1 sibling, 1 reply; 46+ messages in thread
From: David S. Miller @ 2002-05-02 14:03 UTC (permalink / raw)
To: aoliva; +Cc: Joe.Buck, rth, glebourgeois, gcc
From: Alexandre Oliva <aoliva@redhat.com>
Date: 02 May 2002 16:18:52 -0300
On May 2, 2002, "David S. Miller" <davem@redhat.com> wrote:
> and from what I can tell, it is intentional behavior and not a bug in
> the Solaris linker.
If linking with `.libs/libgcj.so -L.libs -lgcj' fails but `-L.libs
-lgcj -lgcj' works, because the linker thinks they're two different
libraries with the same SONAME in the former case and it notices
they're the same library in the latter, it sounds like a linker bug to
me.
Aha! I think this is the key. Maybe we need to specify the
correct '-h' option to Solaris's native linker to make this work?
See:
http://sundocs.princeton.edu:8888/ab2/coll.45.13/LLM/@Ab2PageView/6238?
Specifically, section "Recording a Shared Object Name."
I apologize in advance if this has been talked about already. There
is a lot of material, both in the list archives and other places,
where this topic has been discussed to death and I admit I have not
read all of it yet.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 14:03 ` David S. Miller
@ 2002-05-02 14:06 ` Richard Henderson
0 siblings, 0 replies; 46+ messages in thread
From: Richard Henderson @ 2002-05-02 14:06 UTC (permalink / raw)
To: David S. Miller; +Cc: aoliva, Joe.Buck, glebourgeois, gcc
On Thu, May 02, 2002 at 01:52:15PM -0700, David S. Miller wrote:
> Aha! I think this is the key. Maybe we need to specify the
> correct '-h' option to Solaris's native linker to make this work?
Nope. Already done:
$ objdump -p libgcj.so.3.0.0 | grep SONAME
SONAME libgcj.so.3
r~
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 13:55 ` Richard Henderson
@ 2002-05-02 14:41 ` Rainer Orth
2002-05-02 14:48 ` Richard Henderson
2002-05-02 14:46 ` David S. Miller
1 sibling, 1 reply; 46+ messages in thread
From: Rainer Orth @ 2002-05-02 14:41 UTC (permalink / raw)
To: Richard Henderson
Cc: Alexandre Oliva, David S. Miller, Joe.Buck, glebourgeois, gcc
Richard Henderson writes:
> > ld: fatal: file /sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.0/../../../libgcj.so: recording name `libgcj.so.2' matches that provided by file ./.libs/libgcj.so
>
> But what prompted it to go looking in /sw/test/ in the first place?
> The -L option should have directed the search for -lgcj to ./.libs/.
jv-convert is build like this (OBJ is the build dir, PFX $prefix, ARCH is
sparc-sun-solaris2.8):
/bin/ksh ./libtool --tag=GCJ --mode=link /OBJ/gcc/gcj
-B/OBJ/ARCH/libjava/ -B/OBJ/gcc/ -L/OBJ/ARCH/libjava
-g -O2 -o jv-convert --main=gnu.gcj.convert.Convert
-rpath /PFX/lib -shared-libgcc
libgcj.la -L/OBJ/ARCH/libjava/.libs
libtool expands this to
/OBJ/gcc/gcj -B/OBJ/ARCH/libjava/ -B/OBJ/gcc/
-g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc
-L/OBJ/ARCH/libjava ./.libs/libgcj.so
-L/OBJ/ARCH/libstdc++-v3/src -L/OBJ/ARCH/libstdc++-v3/src/.libs
-lpthread -lrt -ldl
-L/OBJ/gcc -L/PFX/lib/gcc-lib/ARCH/3.1 -L/usr/ccs/bin -L/usr/ccs/lib
-L/PFX/lib/gcc-lib/ARCH/3.1/../../..
-lgcc_s -lgcc_s
-L/OBJ/ARCH/libjava/.libs
-Wl,-R -Wl,/PFX/lib
All those additional -L switches stem from libgcj.la, but haven't been
passed explicitly when building libgcj.la. Instead I've found
compiler_lib_search_path="
-L/OBJ/ARCH/libstdc++-v3/src -L/OBJ/ARCH/libstdc++-v3/src/.libs
-L/OBJ/gcc -L/PFX/lib/gcc-lib/ARCH/3.1 -L/usr/ccs/bin -L/usr/ccs/lib
-L/PFX/lib/gcc-lib/ARCH/3.1/../../.."
in the libtool built/used to create libgcj.la.
The problem obviously is that -L/OBJ/ARCH/libjava/.libs is placed *after*
libgcj.la, so the different copy in /PFX/lib is found first instead. This
happens in libjava/Makefile.am:
## We explicitly link in the libraries we need. This way we don't
## need -nodefaultlibs, so we can still rely on gcj picking up the
## system libraries we need (via the specs file).
## We need the -L so that gcj can find libgcj with `-lgcj'.
## FIXME: should be _libs on some systems.
jv_convert_LDADD = libgcj.la -L$(here)/.libs
Changing the order here (and in a couple of other places) should fix
things. The -L is clearly necessary here for gcj's implicit -lgcj to
work. All this doesn't seem to be an issue for libstdc++ since, unlike
libgcj, no executables are built during a bootstrap.
Rainer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 13:55 ` Richard Henderson
2002-05-02 14:41 ` Rainer Orth
@ 2002-05-02 14:46 ` David S. Miller
2002-05-02 14:49 ` Richard Henderson
1 sibling, 1 reply; 46+ messages in thread
From: David S. Miller @ 2002-05-02 14:46 UTC (permalink / raw)
To: rth; +Cc: ro, aoliva, Joe.Buck, glebourgeois, gcc
From: Richard Henderson <rth@redhat.com>
Date: Thu, 2 May 2002 13:55:46 -0700
On Thu, May 02, 2002 at 10:37:31PM +0200, Rainer Orth wrote:
> http://gcc.gnu.org/ml/java/2001-04/msg00129.html
>
> ld: fatal: file /sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.0/../../../libgcj.so: recording name `libgcj.so.2' matches that provided by file ./.libs/libgcj.so
But what prompted it to go looking in /sw/test/ in the first place?
The -L option should have directed the search for -lgcj to ./.libs/.
It is specified only in the '-rpath' option. The Solaris linker
doesn't document that option, so perhaps libtool is turning it into
something else.
What is '-rpath /sw/test/gcc/SunOS/lib' being expanded into?
I also just noticed that the Solaris linker manpage says that
LD_LIBRARY_PATH does a lot of 'funky stuff'. It modifies the
library search path in nontrivial ways. Maybe this is irrelevant.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 14:41 ` Rainer Orth
@ 2002-05-02 14:48 ` Richard Henderson
2002-05-02 14:50 ` David S. Miller
0 siblings, 1 reply; 46+ messages in thread
From: Richard Henderson @ 2002-05-02 14:48 UTC (permalink / raw)
To: Rainer Orth; +Cc: Alexandre Oliva, David S. Miller, Joe.Buck, glebourgeois, gcc
On Thu, May 02, 2002 at 11:40:58PM +0200, Rainer Orth wrote:
> jv_convert_LDADD = libgcj.la -L$(here)/.libs
>
> Changing the order here (and in a couple of other places) should fix
> things.
Makes sense.
r~
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 14:46 ` David S. Miller
@ 2002-05-02 14:49 ` Richard Henderson
0 siblings, 0 replies; 46+ messages in thread
From: Richard Henderson @ 2002-05-02 14:49 UTC (permalink / raw)
To: David S. Miller; +Cc: ro, aoliva, Joe.Buck, glebourgeois, gcc
On Thu, May 02, 2002 at 02:35:37PM -0700, David S. Miller wrote:
> What is '-rpath /sw/test/gcc/SunOS/lib' being expanded into?
IIRC, "-R".
r~
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 14:48 ` Richard Henderson
@ 2002-05-02 14:50 ` David S. Miller
2002-05-02 14:55 ` Rainer Orth
0 siblings, 1 reply; 46+ messages in thread
From: David S. Miller @ 2002-05-02 14:50 UTC (permalink / raw)
To: rth; +Cc: ro, aoliva, Joe.Buck, glebourgeois, gcc
From: Richard Henderson <rth@redhat.com>
Date: Thu, 2 May 2002 14:48:19 -0700
On Thu, May 02, 2002 at 11:40:58PM +0200, Rainer Orth wrote:
> jv_convert_LDADD = libgcj.la -L$(here)/.libs
>
> Changing the order here (and in a couple of other places) should fix
> things.
Makes sense.
Rainer, thanks for helping us track this down.
Who is going to code up the patch?
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 14:50 ` David S. Miller
@ 2002-05-02 14:55 ` Rainer Orth
2002-05-02 19:22 ` Alexandre Oliva
0 siblings, 1 reply; 46+ messages in thread
From: Rainer Orth @ 2002-05-02 14:55 UTC (permalink / raw)
To: David S. Miller; +Cc: rth, aoliva, Joe.Buck, glebourgeois, gcc
David S. Miller writes:
> Rainer, thanks for helping us track this down.
It's always fun to rebut claims of Solaris brokenness :-)
> Who is going to code up the patch?
I could do it tomorrow night at the earliest: time to go to bed now; and a
day job as well.
Rainer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-01 22:46 ` Alexandre Oliva
2002-05-01 22:57 ` David S. Miller
@ 2002-05-02 15:31 ` Joe Buck
1 sibling, 0 replies; 46+ messages in thread
From: Joe Buck @ 2002-05-02 15:31 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Joe Buck, Richard Henderson, glebourgeois, gcc
>
> On May 2, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:
>
> > ld: fatal: file /u/jbuck/gcc-3.1-pre.sol2/lib/gcc-lib/sparc-sun-solaris2.7/3.1/../../../sparcv9/libgcj.so: recording name `libgcj.so.3' matches that provided by file ./.libs/libgcj.so
Alexandre wrote:
> This is a different problem. It's the hideous bug in Solaris that
> won't let you create a library if it finds another pre-installed
> library with the same SONAME. This is even documented, and it's the
> reason why libjava is (or used to be) disabled on Solaris 7 if it was
> found to be previously installed.
Ah! The right answer.
I blew away the previously-partially-installed libgjc.* files in libdir,
did contrib/update_gcc, and rebuilt, and I got a complete successful
build. The Java libraries seem to require almost twice as much time as
everything else put together, but eventually the build succeeded.
So the combination of CONFIG_SHELL=/bin/ksh and ensuring that there are
no libgjc files lying around in $prefix/lib suffices.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 14:55 ` Rainer Orth
@ 2002-05-02 19:22 ` Alexandre Oliva
2002-05-03 0:45 ` Mark Mitchell
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-02 19:22 UTC (permalink / raw)
To: Rainer Orth, gcc-patches, java, mark
Cc: David S. Miller, rth, Joe.Buck, glebourgeois, gcc
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On May 2, 2002, Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:
> David S. Miller writes:
>> Rainer, thanks for helping us track this down.
> It's always fun to rebut claims of Solaris brokenness :-)
I always like when a misunderstanding of mine gets me enlightened at
the end :-)
Thanks for keeping me straight. Here's the patch I'm testing right
now, on a relatively slow Solaris 7 box. I'm posting it such that
people with access to faster boxes can test it too, and to avoid
duplication of work in translating Rainer's suggestion into a patch.
Mark, if this fixes the problem on Solaris, ok to install in the 3.1
branch?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libjava-solaris.patch --]
[-- Type: text/x-patch, Size: 3990 bytes --]
Index: libjava/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
Suggested by Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
* Makefile.am (jv_convert_LDADD): Bring -L.libs to the front.
(gij_LDADD, rmic_LDADD, rmiregistry_LDADD): Likewise.
* Makefile.in: Rebuilt.
Index: libjava/Makefile.am
===================================================================
RCS file: /cvs/gcc/egcs/libjava/Makefile.am,v
retrieving revision 1.202.2.10
diff -u -p -r1.202.2.10 Makefile.am
--- libjava/Makefile.am 16 Apr 2002 15:52:53 -0000 1.202.2.10
+++ libjava/Makefile.am 3 May 2002 02:15:12 -0000
@@ -431,12 +431,14 @@ EXTRA_jv_convert_SOURCES = $(convert_sou
jv_convert_LDFLAGS = --main=gnu.gcj.convert.Convert \
-rpath $(toolexeclibdir) -shared-libgcc $(THREADLDFLAGS)
jv_convert_LINK = $(GCJLINK)
-## We explicitly link in the libraries we need. This way we don't
-## need -nodefaultlibs, so we can still rely on gcj picking up the
-## system libraries we need (via the specs file).
-## We need the -L so that gcj can find libgcj with `-lgcj'.
-## FIXME: should be _libs on some systems.
-jv_convert_LDADD = libgcj.la -L$(here)/.libs
+## We don't explicitly link in the libraries we need; libgcj.la brings
+## in all dependencies. We need the -L so that gcj can find libgcj
+## with `-lgcj', but it must come first, otherwise the -L flags
+## brought in from libgcj.la would cause the install directories to be
+## searched before the build-tree ones, and we'd get errors because of
+## different libraries with the same SONAME from picky linkers such as
+## Solaris'. FIXME: should be _libs on some systems.
+jv_convert_LDADD = -L$(here)/.libs libgcj.la
## Depend on the spec file to make sure it is up to date before
## linking this program.
jv_convert_DEPENDENCIES = $(convert_source_files:.java=.lo) \
@@ -448,12 +450,8 @@ gij_SOURCES = gij.cc
## `.la' file.
gij_LDFLAGS = -rpath $(toolexeclibdir) -shared-libgcc $(THREADLDFLAGS)
gij_LINK = $(GCJLINK)
-## We explicitly link in the libraries we need. This way we don't
-## need -nodefaultlibs, so we can still rely on gcj picking up the
-## system libraries we need (via the specs file).
-## We need the -L so that gcj can find libgcj with `-lgcj'.
-## FIXME: should be _libs on some systems.
-gij_LDADD = libgcj.la -L$(here)/.libs
+## See jv_convert_LDADD.
+gij_LDADD = -L$(here)/.libs libgcj.la
## Depend on the spec file to make sure it is up to date before
## linking this program.
gij_DEPENDENCIES = libgcj.la libgcj.spec
@@ -464,12 +462,8 @@ EXTRA_rmic_SOURCES = $(rmi_java_source_f
rmic_LDFLAGS = --main=gnu.java.rmi.rmic.RMIC \
-rpath $(toolexeclibdir) -shared-libgcc $(THREADLDFLAGS)
rmic_LINK = $(GCJLINK)
-## We explicitly link in the libraries we need. This way we don't
-## need -nodefaultlibs, so we can still rely on gcj picking up the
-## system libraries we need (via the specs file).
-## We need the -L so that gcj can find libgcj with `-lgcj'.
-## FIXME: should be _libs on some systems.
-rmic_LDADD = libgcj.la -L$(here)/.libs
+## See jv_convert_LDADD.
+rmic_LDADD = -L$(here)/.libs libgcj.la
## Depend on the spec file to make sure it is up to date before
## linking this program.
rmic_DEPENDENCIES = libgcj.la libgcj.spec
@@ -480,12 +474,8 @@ EXTRA_rmiregistry_SOURCES = $(rmi_java_s
rmiregistry_LDFLAGS = --main=gnu.java.rmi.registry.RegistryImpl \
-rpath $(toolexeclibdir) -shared-libgcc $(THREADLDFLAGS)
rmiregistry_LINK = $(GCJLINK)
-## We explicitly link in the libraries we need. This way we don't
-## need -nodefaultlibs, so we can still rely on gcj picking up the
-## system libraries we need (via the specs file).
-## We need the -L so that gcj can find libgcj with `-lgcj'.
-## FIXME: should be _libs on some systems.
-rmiregistry_LDADD = libgcj.la -L$(here)/.libs
+## See jv_convert_LDADD.
+rmiregistry_LDADD = -L$(here)/.libs libgcj.la
## Depend on the spec file to make sure it is up to date before
## linking this program.
rmiregistry_DEPENDENCIES = libgcj.la libgcj.spec
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: toplev-solaris-libjava.patch --]
[-- Type: text/x-patch, Size: 1472 bytes --]
Index: ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* configure.in: Revert 2002-04-18's patch; fixed in libjava.
Index: configure.in
===================================================================
RCS file: /cvs/gcc/egcs/configure.in,v
retrieving revision 1.119.2.12
diff -u -p -r1.119.2.12 configure.in
--- configure.in 26 Apr 2002 21:40:53 -0000 1.119.2.12
+++ configure.in 3 May 2002 02:15:00 -0000
@@ -1379,33 +1379,6 @@ case "${host}" in
;;
esac
-# If we're building libgcj and we're using the Solaris 2.8 linker,
-# then we check for a known problem.
-if test "x${libgcj}" = x && test "${with_gnu_ld}" != yes \
- && test "${is_cross_compiler}" = no; then
-
- case "${host}" in
- sparc-*-solaris2.8)
- if test "$libdir" = '${exec_prefix}/lib';then
- if test "$exec_prefix" = '$(prefix)'; then
- tlibdir="$prefix/lib"
- else
- tlibdir="$exec_prefix/lib"
- fi
- else
- tlibdir="$libdir"
- fi
- if test -f $tlibdir/libgcj.la; then
- echo "*** You've already installed libgcj in $tlibdir." 1>&2
- echo " This causes problems when rebuilding libgcj with the Solaris 2.8 linker." 1>&2
- echo " Either disable the libgcj build, or remove the" 1>&2
- echo " already-installed libgcj files." 1>&2
- exit 1
- fi
- ;;
- esac
-fi
-
# If --enable-shared was set, we must set LD_LIBRARY_PATH so that the
# binutils tools will find libbfd.so.
if [ "${shared}" = "yes" ]; then
[-- Attachment #4: Type: text/plain, Size: 289 bytes --]
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 19:22 ` Alexandre Oliva
@ 2002-05-03 0:45 ` Mark Mitchell
2002-05-03 11:27 ` Alexandre Oliva
2002-05-03 4:05 ` Rainer Orth
2002-05-03 21:56 ` Alexandre Oliva
2 siblings, 1 reply; 46+ messages in thread
From: Mark Mitchell @ 2002-05-03 0:45 UTC (permalink / raw)
To: Alexandre Oliva, Rainer Orth, gcc-patches, java
Cc: David S. Miller, rth, Joe.Buck, glebourgeois, gcc
> Mark, if this fixes the problem on Solaris, ok to install in the 3.1
> branch?
Yes.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 19:22 ` Alexandre Oliva
2002-05-03 0:45 ` Mark Mitchell
@ 2002-05-03 4:05 ` Rainer Orth
2002-05-03 21:56 ` Alexandre Oliva
2 siblings, 0 replies; 46+ messages in thread
From: Rainer Orth @ 2002-05-03 4:05 UTC (permalink / raw)
To: Alexandre Oliva
Cc: gcc-patches, java, mark, David S. Miller, rth, Joe.Buck,
glebourgeois, gcc
Alexandre Oliva writes:
> Thanks for keeping me straight. Here's the patch I'm testing right
> now, on a relatively slow Solaris 7 box. I'm posting it such that
> people with access to faster boxes can test it too, and to avoid
> duplication of work in translating Rainer's suggestion into a patch.
>
> Mark, if this fixes the problem on Solaris, ok to install in the 3.1
> branch?
I've successfully bootstrapped an equivalent (except for comments) patch on
sparc-sun-solaris2.8 with libgcj.la etc. installed in $libdir. The build
completed successfully, while manually building jv-convert with the order
of libgcj.la and -L... inverted fails as expected.
I'll post a separate patch to update install.texi with the obsolete info
about this issue removed, among others.
Rainer
^ permalink raw reply [flat|nested] 46+ messages in thread
* PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-01 13:46 ` Joe Buck
2002-05-01 16:54 ` Alexandre Oliva
@ 2002-05-03 4:52 ` Gerald Pfeifer
2002-05-13 10:00 ` Gerald Pfeifer
1 sibling, 1 reply; 46+ messages in thread
From: Gerald Pfeifer @ 2002-05-03 4:52 UTC (permalink / raw)
To: Joe Buck
Cc: Richard Henderson, Alexandre Oliva, glebourgeois, gcc, gcc-patches
On Wed, 1 May 2002, Joe Buck wrote:
>> Too late. Do
>>
>> CONFIG_SHELL=/bin/ksh ksh ../src/configure [...]
> The installation instructions should be modified if this is required.
"When in doubt, to the safe thing."
How about the following patch?
Gerald
2002-05-03 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
* doc/install.texi (Specific, *-*-solaris2*): Update passus on
setting CONFIG_SHELL to /bin/ksh and remove alternate trick to
(possibly) work around broken /bin/sh.
Index: doc/install.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.92.2.21
diff -u -3 -p -r1.92.2.21 install.texi
--- doc/install.texi 2 May 2002 23:29:52 -0000 1.92.2.21
+++ doc/install.texi 3 May 2002 11:50:01 -0000
@@ -3470,9 +3470,7 @@ GCC you first have to install a pre-buil
The Solaris 2 @command{/bin/sh} will often fail to configure
@file{libstdc++-v3}, @file{boehm-gc} or
@file{libjava}. If you encounter this problem, set @env{CONFIG_SHELL} to
-@command{/bin/ksh} in your environment and run @command{make bootstrap} again.
-Another possibility that sometimes helps is to remove
-@file{*-*-solaris2*/config.cache}.
+@command{/bin/ksh} in your environment before running @command{configure}.
Solaris 2 comes with a number of optional OS packages. Some of these
packages are needed to use GCC fully, namely @code{SUNWarc},
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-03 0:45 ` Mark Mitchell
@ 2002-05-03 11:27 ` Alexandre Oliva
0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-03 11:27 UTC (permalink / raw)
To: Mark Mitchell
Cc: Rainer Orth, gcc-patches, java, David S. Miller, rth, Joe.Buck,
glebourgeois, gcc
On May 3, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
>> Mark, if this fixes the problem on Solaris, ok to install in the 3.1
>> branch?
> Yes.
After verification that it fixed the problem on Solaris 8, where the
problem showed up, confirmed by Rainer, I've checked this in. Thanks
again, Rainer!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-02 19:22 ` Alexandre Oliva
2002-05-03 0:45 ` Mark Mitchell
2002-05-03 4:05 ` Rainer Orth
@ 2002-05-03 21:56 ` Alexandre Oliva
2002-05-03 22:04 ` David S. Miller
2 siblings, 1 reply; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-03 21:56 UTC (permalink / raw)
To: Rainer Orth
Cc: gcc-patches, java, mark, David S. Miller, rth, Joe.Buck,
glebourgeois, gcc
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
On May 2, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:
> Index: libjava/ChangeLog
> from Alexandre Oliva <aoliva@redhat.com>
> Suggested by Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
> * Makefile.am (jv_convert_LDADD): Bring -L.libs to the front.
> (gij_LDADD, rmic_LDADD, rmiregistry_LDADD): Likewise.
> * Makefile.in: Rebuilt.
Here's a patch that adjusts the installation instructions to reflect
the fixed problem. Mark, ok for 3.1 (and mainline)?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gccdoc-solaris-libjava.patch --]
[-- Type: text/x-patch, Size: 1290 bytes --]
Index: gcc/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* doc/install.texi (*-*-solaris2.8): Removed section about libjava
problems with Sun linker.
Index: gcc/doc/install.texi
===================================================================
RCS file: /cvs/gcc/egcs/gcc/doc/install.texi,v
retrieving revision 1.92.2.21
diff -u -p -r1.92.2.21 install.texi
--- gcc/doc/install.texi 2 May 2002 23:29:52 -0000 1.92.2.21
+++ gcc/doc/install.texi 4 May 2002 04:55:53 -0000
@@ -3590,21 +3590,6 @@ the Solaris 7 Recommended Patch Cluster.
<p>
<hr>
@end html
-@heading @anchor{*-*-solaris2.8}*-*-solaris2.8
-
-The Solaris 8 linker fails to link some @samp{libjava} programs if
-previously-installed GCC java libraries already exist in the configured
-prefix. For this reason, @command{configure} will report an error on
-Solaris 8 if an existing @samp{libgcj} is found in the appropriate
-install directory and the system linker is in use. In this case, you
-can configure with a different prefix, or delete or rename the existing
-@samp{libgcj} library files before configuring, or configure using
-@option{--disable-libgcj}.
-
-@html
-<p>
-<hr>
-@end html
@heading @anchor{sparc-sun-sunos4*}sparc-sun-sunos4*
A bug in the SunOS 4 linker will cause it to crash when linking
[-- Attachment #3: Type: text/plain, Size: 289 bytes --]
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-03 21:56 ` Alexandre Oliva
@ 2002-05-03 22:04 ` David S. Miller
2002-05-03 22:22 ` Mark Mitchell
2002-05-03 22:23 ` Alexandre Oliva
0 siblings, 2 replies; 46+ messages in thread
From: David S. Miller @ 2002-05-03 22:04 UTC (permalink / raw)
To: aoliva; +Cc: ro, gcc-patches, java, mark, rth, Joe.Buck, glebourgeois, gcc
From: Alexandre Oliva <aoliva@redhat.com>
Date: 04 May 2002 01:56:37 -0300
Here's a patch that adjusts the installation instructions to reflect
the fixed problem. Mark, ok for 3.1 (and mainline)?
I believe that doc fixes don't need to go through Mark for
3.1 approval.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-03 22:04 ` David S. Miller
@ 2002-05-03 22:22 ` Mark Mitchell
2002-05-03 22:23 ` Alexandre Oliva
1 sibling, 0 replies; 46+ messages in thread
From: Mark Mitchell @ 2002-05-03 22:22 UTC (permalink / raw)
To: David S. Miller, aoliva
Cc: ro, gcc-patches, java, rth, Joe.Buck, glebourgeois, gcc
--On Friday, May 03, 2002 09:53:12 PM -0700 "David S. Miller"
<davem@redhat.com> wrote:
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 04 May 2002 01:56:37 -0300
>
> Here's a patch that adjusts the installation instructions to reflect
> the fixed problem. Mark, ok for 3.1 (and mainline)?
>
> I believe that doc fixes don't need to go through Mark for
> 3.1 approval.
Correct.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-03 22:04 ` David S. Miller
2002-05-03 22:22 ` Mark Mitchell
@ 2002-05-03 22:23 ` Alexandre Oliva
2002-05-03 22:28 ` David S. Miller
1 sibling, 1 reply; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-03 22:23 UTC (permalink / raw)
To: David S. Miller
Cc: ro, gcc-patches, java, mark, rth, Joe.Buck, glebourgeois, gcc
On May 4, 2002, "David S. Miller" <davem@redhat.com> wrote:
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 04 May 2002 01:56:37 -0300
> Here's a patch that adjusts the installation instructions to reflect
> the fixed problem. Mark, ok for 3.1 (and mainline)?
> I believe that doc fixes don't need to go through Mark for
> 3.1 approval.
Hmm... You're right. But I still need approval from someone with
doc or global write privileges. Like you :-) Do I hear an `ok'? :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-03 22:23 ` Alexandre Oliva
@ 2002-05-03 22:28 ` David S. Miller
2002-05-03 22:41 ` Alexandre Oliva
0 siblings, 1 reply; 46+ messages in thread
From: David S. Miller @ 2002-05-03 22:28 UTC (permalink / raw)
To: aoliva; +Cc: ro, gcc-patches, java, mark, rth, Joe.Buck, glebourgeois, gcc
From: Alexandre Oliva <aoliva@redhat.com>
Date: 04 May 2002 02:23:07 -0300
On May 4, 2002, "David S. Miller" <davem@redhat.com> wrote:
> I believe that doc fixes don't need to go through Mark for
> 3.1 approval.
Hmm... You're right. But I still need approval from someone with
doc or global write privileges. Like you :-) Do I hear an `ok'? :-)
I approve your doc changes. :-)
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)
2002-05-03 22:28 ` David S. Miller
@ 2002-05-03 22:41 ` Alexandre Oliva
0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-03 22:41 UTC (permalink / raw)
To: David S. Miller
Cc: ro, gcc-patches, java, mark, rth, Joe.Buck, glebourgeois, gcc
On May 4, 2002, "David S. Miller" <davem@redhat.com> wrote:
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 04 May 2002 02:23:07 -0300
> On May 4, 2002, "David S. Miller" <davem@redhat.com> wrote:
>> I believe that doc fixes don't need to go through Mark for
>> 3.1 approval.
> Hmm... You're right. But I still need approval from someone with
> doc or global write privileges. Like you :-) Do I hear an `ok'? :-)
> I approve your doc changes. :-)
D'oh. Rainer had already checked it in.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-03 4:52 ` PATCH for " Gerald Pfeifer
@ 2002-05-13 10:00 ` Gerald Pfeifer
2002-05-13 14:55 ` Alexandre Oliva
0 siblings, 1 reply; 46+ messages in thread
From: Gerald Pfeifer @ 2002-05-13 10:00 UTC (permalink / raw)
To: Joe Buck
Cc: Richard Henderson, Alexandre Oliva, glebourgeois, gcc, gcc-patches
Just to make sure, I have not yet committed the patch below.
Should I? (It's too late for 3.1, but would fit for 3.1.1 and the
online docs.)
Gerald
On Fri, 3 May 2002, Gerald Pfeifer wrote:
> "When in doubt, to the safe thing."
>
> How about the following patch?
>
> 2002-05-03 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
>
> * doc/install.texi (Specific, *-*-solaris2*): Update passus on
> setting CONFIG_SHELL to /bin/ksh and remove alternate trick to
> (possibly) work around broken /bin/sh.
>
> Index: doc/install.texi
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
> retrieving revision 1.92.2.21
> diff -u -3 -p -r1.92.2.21 install.texi
> --- doc/install.texi 2 May 2002 23:29:52 -0000 1.92.2.21
> +++ doc/install.texi 3 May 2002 11:50:01 -0000
> @@ -3470,9 +3470,7 @@ GCC you first have to install a pre-buil
> The Solaris 2 @command{/bin/sh} will often fail to configure
> @file{libstdc++-v3}, @file{boehm-gc} or
> @file{libjava}. If you encounter this problem, set @env{CONFIG_SHELL} to
> -@command{/bin/ksh} in your environment and run @command{make bootstrap} again.
> -Another possibility that sometimes helps is to remove
> -@file{*-*-solaris2*/config.cache}.
> +@command{/bin/ksh} in your environment before running @command{configure}.
>
> Solaris 2 comes with a number of optional OS packages. Some of these
> packages are needed to use GCC fully, namely @code{SUNWarc},
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-13 10:00 ` Gerald Pfeifer
@ 2002-05-13 14:55 ` Alexandre Oliva
2002-05-14 2:54 ` Gerald Pfeifer
0 siblings, 1 reply; 46+ messages in thread
From: Alexandre Oliva @ 2002-05-13 14:55 UTC (permalink / raw)
To: Gerald Pfeifer
Cc: Joe Buck, Richard Henderson, glebourgeois, gcc, gcc-patches
On May 13, 2002, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:
> Should I? (It's too late for 3.1, but would fit for 3.1.1 and the
> online docs.)
Sounds good to me.
>> 2002-05-03 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
>>
>> * doc/install.texi (Specific, *-*-solaris2*): Update passus on
>> setting CONFIG_SHELL to /bin/ksh and remove alternate trick to
>> (possibly) work around broken /bin/sh.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8
2002-05-13 14:55 ` Alexandre Oliva
@ 2002-05-14 2:54 ` Gerald Pfeifer
0 siblings, 0 replies; 46+ messages in thread
From: Gerald Pfeifer @ 2002-05-14 2:54 UTC (permalink / raw)
To: Alexandre Oliva
Cc: Joe Buck, Richard Henderson, glebourgeois, gcc, gcc-patches
On 13 May 2002, Alexandre Oliva wrote:
> Sounds good to me.
>
>>> 2002-05-03 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
>>>
>>> * doc/install.texi (Specific, *-*-solaris2*): Update passus on
>>> setting CONFIG_SHELL to /bin/ksh and remove alternate trick to
>>> (possibly) work around broken /bin/sh.
Thanks! I committed it to mainline and queued it for GCC 3.1.1.
(At least the online version will already be update in time for the
GCC 3.1 release.)
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2002-05-14 9:14 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-30 4:51 Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8 glebourgeois
2002-04-30 20:29 ` Alexandre Oliva
2002-05-01 9:25 ` Joe Buck
2002-05-01 13:10 ` Alexandre Oliva
2002-05-01 13:12 ` Joe Buck
2002-05-01 13:29 ` Richard Henderson
2002-05-01 13:46 ` Joe Buck
2002-05-01 16:54 ` Alexandre Oliva
2002-05-01 16:58 ` Phil Edwards
2002-05-01 17:10 ` Joe Buck
2002-05-01 19:52 ` Alexandre Oliva
2002-05-03 4:52 ` PATCH for " Gerald Pfeifer
2002-05-13 10:00 ` Gerald Pfeifer
2002-05-13 14:55 ` Alexandre Oliva
2002-05-14 2:54 ` Gerald Pfeifer
2002-05-01 20:39 ` Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help) Joe Buck
2002-05-01 22:46 ` Alexandre Oliva
2002-05-01 22:57 ` David S. Miller
2002-05-02 9:35 ` Tom Tromey
2002-05-02 12:19 ` Alexandre Oliva
2002-05-02 13:37 ` Rainer Orth
2002-05-02 13:55 ` Richard Henderson
2002-05-02 14:41 ` Rainer Orth
2002-05-02 14:48 ` Richard Henderson
2002-05-02 14:50 ` David S. Miller
2002-05-02 14:55 ` Rainer Orth
2002-05-02 19:22 ` Alexandre Oliva
2002-05-03 0:45 ` Mark Mitchell
2002-05-03 11:27 ` Alexandre Oliva
2002-05-03 4:05 ` Rainer Orth
2002-05-03 21:56 ` Alexandre Oliva
2002-05-03 22:04 ` David S. Miller
2002-05-03 22:22 ` Mark Mitchell
2002-05-03 22:23 ` Alexandre Oliva
2002-05-03 22:28 ` David S. Miller
2002-05-03 22:41 ` Alexandre Oliva
2002-05-02 14:46 ` David S. Miller
2002-05-02 14:49 ` Richard Henderson
2002-05-02 14:03 ` David S. Miller
2002-05-02 14:06 ` Richard Henderson
2002-05-02 15:31 ` Joe Buck
2002-05-01 23:11 ` Richard Henderson
2002-05-02 3:45 ` Rainer Orth
2002-05-02 8:06 ` Joe Buck
2002-05-02 9:36 ` Gerald Pfeifer
2002-05-02 7:57 ` Joe Buck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).