libtool, java woes

Alexandre Oliva
Mon Apr 9 00:11:00 GMT 2001

On Apr  8, 2001, Jeff Sturm <> wrote:

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


> 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

> 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
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

More information about the Java mailing list