Re: Linking one library against another + static vs. shared

[Ralf Wildenhues]

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