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

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)

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

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)

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

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