This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Enable PIC for mips*-*-*


On Tue, Nov 20, 2001 at 08:17:53PM +0100, Maciej W. Rozycki wrote:
> On Mon, 19 Nov 2001, H . J . Lu wrote:
> 
> > libtool should do whatever ld does. When I do
> > 
> > # gcc -shared -o libfoo.so foo.o -lbar
> > 
> > and there is only libbar.a, no libar.so, ld won't put references to
> > libbar.a in libfoo.so. I don't want libtool to put any references to
> > libbar.a in libfoo.la either, at least not under Linux.
> 
>  You need a libbar.a reference in libfoo.la since the file serves for both
> libfoo.so and libfoo.a.  While the in case of ELF/Linux the former does
> record shared objects it depends on in its dynamic section, the latter
> definitely does not and libbar.a must be linked against explicitly when
> linking programs statically.

That is not how ld works on Linux. When you do

# gcc -shared -o libfoo.so foo.o -lbar

the resulting libfoo.so has no unresolved references which can be
satisfied by libbar.a. Ld has resolved those references by pulling
in their definitions from libbar.a. libfoo.so has no dependency on
libbar.a. libfoo.a is different. It is created by ar. You may or may
not need to add -lbar for linking executables since ld treats archives
differtently from DSOs. What I have been trying to say is libtool
shouldn't pretend it knows more than ld. It really doesn't. It is
so screwed up in this case.


H.J.


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