[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sander Niemeijer
Subject: Fwd: Linking one library against another + static vs. shared
Date: Wed, 12 Jan 2011 12:03:40 +0100

Dear all,

Since I am still being faced with the issue, I would like to bring this to your attention once more.

FYI: Where I am currently experiencing the problem in practice is with linking our shared libraries against the HDF4 software, which on many systems is installed with only static libraries (and it comes with libtool .la files). Since the dependencies on HDF4 are, when there are only static libraries, not included in the .la file of our library, people trying to link against our library will get build errors.

Could you please let me know whether there is any chance of getting the acknowledged bug for issue 1 resolved (the libfoo library not being included as a dependency in the libbar.la file)?

Best regards,

Begin forwarded message:

From: Sander Niemeijer <address@hidden>
Date: 8 oktober 2010 16:47:44 GMT+02:00
To: Libtool <address@hidden>
Cc: Ralf Wildenhues <address@hidden>
Subject: Re: Linking one library against another + static vs. shared

Dear all,

The following issue from last year still seems to be unfixed with the recent 2.4 release of libtool (or did I miss something?) I was just wondering whether there is still some prospect that this issue gets resolved in a future release of libtool.

Best regards,

On 25 jul 2009, at 11:45, Ralf Wildenhues wrote:

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


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]