PATCH: Enable PIC for mips*-*-*

Maciej W. Rozycki macro@ds2.pg.gda.pl
Tue Nov 13 15:03:00 GMT 2001


On Tue, 20 Nov 2001, H . J . Lu wrote:

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

 You are right here -- somehow I've forgotten libbar is an ar archive,
sorry.  However from a program's point of view, it doesn't really matter
if libbar is shared or static.  For libfoo.so a program needn't care of
libfoo's dependencies.  For libfoo.a it must.

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

 I disagree.  Libfoo.la is used for linking against libfoo, whether it's
libfoo.so or libfoo.a.  While for the former a -lbar dependency is
unnecessary, but harmless, for the latter it's mandatory as there might be
unresolved references to symbols from libbar in libfoo.a.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +



More information about the Gcc-patches mailing list