This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: Enable PIC for mips*-*-*
- From: "H . J . Lu" <hjl at lucon dot org>
- To: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- Cc: Alexandre Oliva <aoliva at redhat dot com>,Eric Christopher <echristo at cygnus dot com>,binutils at sourceware dot cygnus dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 20 Nov 2001 12:58:01 -0800
- Subject: Re: PATCH: Enable PIC for mips*-*-*
- References: <20011119101225.A7285@lucon.org> <Pine.GSO.3.96.1011120191018.20958D-100000@delta.ds2.pg.gda.pl>
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.