libtool, java woes

Jeff Sturm
Sun Apr 8 17:26:00 GMT 2001

I've spent much of my weekend trying to understand why the java testsuite
failures on the release branch.  I have a RH 7 machine that routinely
fails to run the testsuite when built with --enable-threads, while another
with RH 6.something is normal.

The core issue is that the libtool currently installed on the branch does
not preserve order of libraries when linking.  I understand that link
order is complicated by interlibrary dependencies, but even when I attempt
to include -lpthread first in the link command, libtool moves it to dead

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

My questions are:

1) Is this a real problem?  I haven't seen anyone else report it.  Is it
likely to be broken only on RH 7 with glibc-2.1.92?  If so, do we try to
fix it or accept that it is broken and not support it?  (In other words,
do we blame gcc or glibc?  There've got to be other RH 7 users who will
try the same thing... I have no idea if glibc 2.2 makes any difference.)

Last I checked there aren't enough results posted to gcc-testresults with
java enabled to give a clear picture.  (And those that are probably don't
have --enable-threads anyway.)  I'd be very happy if I could stop figuring
out why java breaks every week and use what little time I have to fix real
problems... <sigh>

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

My feeling is that allowing libtool to muck with the link order is asking
for trouble, but I scarcely know libtool, so somebody please feel free to
tell me I am wrong.

3) Is it a good idea long-term to continue this interdependence between
libstdc++ and libjava?  It is a little unusual in that the other language
runtimes are independent.  There is a danger that those working on
libstdc++ might never test gcj before submitting patches.  I'd bet not
everyone who submits patches to libsupc++ realizes they are affecting

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... gcj and g++ have distinct
requirements for object allocation, EH, etc.  The bits that must be shared
are in libgcc_s, right?

4) Will --enable-threads ever be the default?  As long as the majority of
users build and test without it, some bugs will go unnoticed.  Java is
different than the other languages in that it is almost useless without

5) Looking for a workaround I stumbled across the -pthread option
to gcc.  This doesn't appear in any documentation that I could find,
though it does the right thing by forcing -lpthread to come before other
libraries.  Unfortunately it is specific to Linux.  Other platforms use a
variety of options (-mthreads, -pthreads, -threads) to do the same
thing.  Is there any value to a common argument that means use the
prevailing thread library available?  If not, should these all go away?


More information about the Java mailing list