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.
