[Top][All Lists]

[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 <> wrote:
On Tue, 29 Jun 2021, Oleg Smolsky wrote:

> ...and I have figured out the source of the mystery linker flags: zmq build
> leaves file which contains this:
> # Libraries that this one depends upon.
> dependency_libs=' -lrt -lpthread /opt/gcc-10/lib/../lib64/'
> 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 file was provided with the compiler.

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

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?

The compilation toolchain you are using is set up to not put its
libraries in the default system directories.  As a result, the 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. 


reply via email to

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