Re: libtool, java woes

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr  8, 2001, Jeff Sturm <jsturm@one-point.com> wrote:

> That didn't become a problem for libjava until libsupc++ began using CXX
> to link:

> http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01870.html

> Until then, -lc didn't appear in deplibs so the link order didn't really
> matter.

Yep.  libsupc++ is linked with -lc.  Since libsupc++ appears before
-lpthread in the libgcj link command line, -lc gets linked in first.
The solution is to move -lpthread first, or get libsupc++ linked with
-lpthread.  The former is probably best for libgcj.

> 2) If we do want to fix it, do we attempt to change libtool or work around
> it?  I'm not suggesting we revert the patch because it is important for
> libstdc++.

> My feeling is that allowing libtool to muck with the link order is asking
> for trouble

It doesn't muck with the link order.  It does it exactly right:
libsupc++ goes in first, along with its dependencies.  Then comes
libpthread.  Unfortunately, libsupc++ brings in the wrong
dependencies.

> I understand why the two language frontends are codependent.  But very
> little of the language runtimes are actually shared.  If those pieces
> moved to libjava there might be fewer problems ahead.  Besides, it is not
> clear to me why libsupc++ ought to be shared...

What I don't understand is why libgcj is linked with libsupc++, and
not with libstdc++.  Linking with libsupc++ means that, if a program
is linked with both libstdc++ and libgcj, it may get two copies of
libsupc++'s symbols (because libstdc++ isn't linked with libsupc++;
rather it contains copies of its symbols).

-- 
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    *Please* write to mailing lists, not to me