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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
