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

On Tue, Jun 29, 2021 at 3:30 PM Bob Friesenhahn <
[email protected]> 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.