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