libtool, java woes

Mon Apr 9 00:11:00 GMT 2001

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