Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[glebourgeois]

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.

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Alexandre Oliva]

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

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Joe Buck]

> 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.

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Alexandre Oliva]

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

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Joe Buck]

> >> 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.

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Richard Henderson]

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~

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Joe Buck]

> 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).

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Alexandre Oliva]

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

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Phil Edwards]

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

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Joe Buck]

> 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.

Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Alexandre Oliva]

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

PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Gerald Pfeifer]

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},

Re: PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Gerald Pfeifer]

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},

Re: PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Alexandre Oliva]

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

Re: PATCH for Re: Bootstrap error with gcc-20020429 snapshot on Sun / Solaris8

[Gerald Pfeifer]

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/

Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Joe Buck]

> 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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Alexandre Oliva]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[David S. Miller]

   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...

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Tom Tromey]

>>>>> "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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Alexandre Oliva]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Rainer Orth]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Richard Henderson]

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~

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Rainer Orth]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Richard Henderson]

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~

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[David S. Miller]

   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?

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Rainer Orth]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Alexandre Oliva]

[-- 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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Mark Mitchell]

> 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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Alexandre Oliva]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Rainer Orth]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Alexandre Oliva]

[-- 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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[David S. Miller]

   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.

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Mark Mitchell]

--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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Alexandre Oliva]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[David S. Miller]

   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. :-)

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Alexandre Oliva]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[David S. Miller]

   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.

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Richard Henderson]

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~

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[David S. Miller]

   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.

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Richard Henderson]

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~

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Joe Buck]

> 
> 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.

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Richard Henderson]

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~

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Rainer Orth]

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

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Joe Buck]

[ 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.

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Gerald Pfeifer]

[ 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/

Re: Still failing to bootstrap on Solaris (CONFIG_SHELL doesn't help)

[Joe Buck]

> 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.