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