Re: Unhelpful automatic 3rd-party library linkage

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


On Tue, Jun 29, 2021 at 10:57 AM Oleg Smolsky <[email protected]> wrote:

> Hello there! I'm using automake+libtool for building C++ code and hitting
> a peculiar issue with 3rd-party libraries. It comes up when a library is
> built with one version of GCC and then the application is built with a
> newer compler.
>
> So, given the following wrapper lib that pulls libzmq:
>
> noinst_LTLIBRARIES += libnsevent.la
> nodist_libnsevent_la_SOURCES = libs/nsevent/wrapper.cpp
> libnsevent_la_LIBADD = -lzmq
>
> Libtool results in the following g++ invocation when linking the
> application:
>
>  /opt/gcc-11/bin/g++ -std=c++17 -Wl,-rpath -Wl,/opt/gcc-11/lib64
> -Wl,-rpath -Wl,/opt/3p/lib -o ns_conn_test
> libs/netsvc/test/ns_conn_test/src/cpp/NsConnTest.o  -L/opt/3p/lib
> ./.libs/libnsevent.a /opt/3p/lib/libzmq.so
> /opt/gcc-9/lib/../lib64/libstdc++.so /opt/gcc-11/lib/../lib64/libstdc++.so
> -lpthread -lrt -ldl -lm -lz -Wl,-rpath -Wl,/opt/3p/lib -Wl,-rpath
> -Wl,/opt/gcc-9/lib/../lib64 -Wl,-rpath -Wl,/opt/gcc-11/lib/../lib64
> -Wl,-rpath -Wl,/opt/3p/lib -Wl,-rpath -Wl,/opt/gcc-9/lib/../lib64
> -Wl,-rpath -Wl,/opt/gcc-11/lib/../lib64
>
> It looks like GCC9 references come from libzmq:
>
> $ ldd /opt/3p/lib/libzmq.so | grep libstd
>         libstdc++.so.6 => /opt/gcc-9/lib/../lib64/libstdc++.so.6
> (0x00007f95f8d9f000)
>
> Obviously the 3rd-party library was built a while ago with GCC9. At the
> time it was linked to the compiler's runtime... but now the main
> application has moved to GCC11 and I'm linking to the runtime that is
> correct right now.
>
> It looks like automake/libtool try to be helpful and check the library's
> dependencies... but that gets in the way as the new libstdc++ is a strict
> superset of the old one. They maintain ABI compatibility and so scenarios
> like these are supported.
>
> Is there a way to suppress dependency tracking for the 3rd-party
> libraries? I wish Libtool/automake was not trying to be smart and simply
> passed "-lzmq" directly to the linker. Yet instead, the actual .so file is
> discovered and then its libstdc++.so is linked. This is just wrong for the
> scenario at hand.
>
> Thanks in advance,
> Oleg.
>