[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linking one library against another + static vs. shared
From: |
Ralf Wildenhues |
Subject: |
Re: Linking one library against another + static vs. shared |
Date: |
Sat, 25 Jul 2009 11:45:09 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-15) |
Hello Sander,
* Sander Niemeijer wrote on Tue, Jul 21, 2009 at 05:35:52PM CEST:
> Suppose we have a library foo that is build with autoconf/automake/
> libtool and gets installed. Now, the person who installed this
> package used (for whatever reason) a --disable-shared option at
> configure time, so only a static version of libfoo gets installed.
>
> Now introduce a second library bar (in a separate package) that is
> also build with autoconf/automake/libtool and that uses
> functionality of libfoo. For the bar library both a static and
> shared library are build.
> In order to link bar against foo I use a 'libbar_la_LIBADD = -L$
> (SOMEPATH)/lib -lfoo'.
>
> The main issue I found is:
>
> * Issue 1
> When compiling libbar, libtool includes libfoo.a when linking the
> shared version of libbar, but for the static version of libbar the
> libfoo library is *not* included.
This seems ok to me.
> Furthermore, the libfoo library is
> also not included as a dependency in the libbar.la file.
This would seem to be a bug. Fixing this should also fix linking
against the static version of libfoo (iff the libfoo.la file is used
for linking).
> The result of this is that a default linkage (with libtool) of an
> executable against libbar will work fine (since it will use the
> dynamic library), but trying to link libbar statically against the
> executable will fail (since the link step won't include libfoo).
> Note that linking libbar statically against the executable will work
> fine if libfoo was build/installed with both static and dynamic
> library creation enabled (since in that case there will be a
> dependency to libfoo.la included in the libbar.la file).
Ah.
> So I thought, what would happen if I just try to link libbar against
> the libfoo.a file, thus bypassing the libfoo.la file (i.e. use
> 'libbar_la_LIBADD = $(SOMEPATH)/lib/libfoo.a')?
> And this brought me to:
>
> * Issue 2
> This resulted in a very weird call to ar:
> ---
> libtool: link: ar cru .libs/libbar.a $(SOMEPATH)/lib/libfoo.a bar.o
Yup, seems weird, and broken.
> Now, I know that linking a static library against a shared library
> is not portable, but:
> 1) I am doing this only on a Linux and Mac OS X system and both
> systems produce PIC objects by default (also for static libraries),
Wrong. OS X produces PIC objects by default. On GNU/Linux, PIC is not
produced by default; however, specifically x86 allows you to relocate
non-PIC code through expensive, killing-page-sharing text relocations.
Try on x86_64 and it will fail.
> so it should be allowed.
That's yet another question, and I acknowledge that libtool's answer
to this is about as inconsistent as all demands have been on this list
throughout the years. ;-)
> 2) libtool only presents a warning about linking a static library
> against a shared library for the setup of issue 2 (linking against
> libfoo.a), but *not* for the setup of issue 1 (link using -L<path> -
> lfoo), which seems inconsistent to me.
Well, one thing could be that libtool might not actually be able to know
which -lfoo the linker uses to actually link. So yes, a QoI issue.
> What I would have expected is that in all cases (both for linking
> against libfoo.a and for linking using '-L<path> -lfoo') libfoo
> would be included as a dependency in the libbar.la file. And under
> no circumstance should the libfoo.a contents be linked into the
> libbar libraries.
Yes and yes. Having two instances of the same code in different
installed libraries is a recipe for disaster.
> It is, in my opinion, the final link step (i.e.
> when creating the executable) that should, by investigating the
> libbar dependencies (either a libfoo.la or a libfoo.a reference),
> pick up the appropriate libfoo library (either static or shared,
> whichever is available/needed) and include it in the link line.
Yes.
Cheers,
Ralf