libtool
[Top][All Lists]
Advanced

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

Re: [EXTERNAL] Re: Unhelpful automatic 3rd-party library linkage


From: Oleg Smolsky
Subject: Re: [EXTERNAL] Re: Unhelpful automatic 3rd-party library linkage
Date: Tue, 29 Jun 2021 15:48:19 -0700



On Tue, Jun 29, 2021 at 3:30 PM Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote:
On Tue, 29 Jun 2021, Oleg Smolsky wrote:

> ...and I have figured out the source of the mystery linker flags: zmq build
> leaves libzmq.la file which contains this:
>
> # Libraries that this one depends upon.
> dependency_libs=' -lrt -lpthread /opt/gcc-10/lib/../lib64/libstdc++.la'
>
> It looks like automake/libtool finds this file (BTW, when is it found?) and
> transforms `-lzmq` into a whole bunch of things (with explicit .so names
> and dependencies)...

Yes, that is part of the function of libtool. In fact (as you can
see), the libstdc++.la file was provided with the compiler.

These are features that you may love or hate depending on what you are
doing.

Right, I use these features for tracking dependencies in our product build... yet it breaks things when a 3rd-party lib is shipped. My current solution is to strip the ".la" file from all automake/libtool-based 3rd-party libs that we build/ship. Is that resonable?
 

[...snip...]
The compilation toolchain you are using is set up to not put its
libraries in the default system directories.  As a result, the
libstc++.so.6 file needs to be found somehow.

Indeed! And I do that with explicit -L and -Wl,--rpath options when I link the application. The 3rd-party libs use the same technique... but I don't rebuild 'em on every compiler upgrade (because I can get away with that). The arrangement only broke when the product build (which uses automake/libtool) found an ".la" file from a 3rd-party project and I moved between compiler versions... which to me looks like a leaky abstraction in this case. 

Oleg.

reply via email to

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