Linking one library against another + static vs. shared

[Sander Niemeijer]

Hi,

I found an issue (actually more than one) with libtool when trying to  
build a libtool library that links against another (static) libtool  
library.
I got the same results with both libtool 2.2.4 and 2.2.6a. And I have  
tried it on both a Linux and Mac OS X system.

The setup is as follows:

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. Furthermore, the libfoo library is  
also not included as a dependency in the libbar.la file.
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).


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
---
Which means that the libbar.a archive ends up containing bar.o and the  
libfoo.a archive. I would have understood adding the libfoo.a  
*contents* to the libbar.a archive, but adding the archive itself is  
(as far as I know) just plain wrong. Trying to link the executable  
against this libbar.a archive also fails again (the foo symbols can  
not be found).

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), so  
it should be allowed.
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.


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


Best regards,
Sander Niemeijer