This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libtool: link order problem affecting gij


On May 16, 2001, Bryce McKinlay <bryce@waitaki.otago.ac.nz> wrote:

> Jeff Sturm wrote:
>> On Sun, 13 May 2001, Bryce McKinlay wrote:
>> > libtool inserting lib flags ("-lgcc_s -lc -lgcc_s") into the gcj link
>> > command line _before_ other lib flags which we are passing to it. This
>> > means that libc is being linked before libpthread, which is bad:
>> 
>> Yeah.  This has been happening for a little while:
>> 
>> http://gcc.gnu.org/ml/java/2001-04/msg00297.html

>> Does Zack's patch help?
>> 
>> http://gcc.gnu.org/ml/java-patches/2001-q2/msg00166.html
>> 
>> By eliminating libsupc++ from the build, its side effects (linking with
>> explicit -lc) should go away.

> Zack's patch does indeed fix this problem and I notice that he has checked
> it in. Thanks Zack!

Seconded.

FYI, my current inclination is to arrange for libtool to not add to a
library's dependencies any switches passed implicitly by the compiler
driver to the linker.  I'm not convinced this is right at all times
(perhaps only for convenience libraries?), but it would have avoided
this problem.

To clue other libtoolers into the problem: libjava is thread-aware, so
it must be linked with the thread library.  However, the thread
library must be linked in before the regular (thread-unaware) C
library.  The problem seems to be that libtool was picking the
dependency list from a C++ convenience library, that included the
shared libgcc and libc, as above, which resulted in libc being linked
in before the thread library.

One simple solution would have been to move -lpthread first in the
list of dependencies of libjava.  But I'd hope libtool might be more
helpful in cases in which library ordering matters so much.  I'm not
sure we should introduce thread-awareness in libtool (actually, extend
the almost-do-nothing already-existing thread flag) or somehow adjust
libtool such that the postdeps of the compiler are handled as a unit,
or something like that.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]