Home Original page

PATCH: Enable PIC for mips*-*-*

H . J . Lu hjl@lucon.org
Sun Nov 11 03:10:00 GMT 2001 
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.
More information about the Binutils mailing list