On Tue, Jun 29, 2021 at 3:30 PM Bob Friesenhahn < bfrie...@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.
