libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unhelpful automatic 3rd-party library linkage


From: Bob Friesenhahn
Subject: Re: Unhelpful automatic 3rd-party library linkage
Date: Tue, 29 Jun 2021 17:22:52 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Tue, 29 Jun 2021, Oleg Smolsky wrote:

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.

Are you absolutely sure that the above is true? You specified c++17 when compiling your application. Are the libstdc++ ABI's the same across GCC versions and C++ language versions?

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.

Assuming that the whole system does not have these directories in the default search path (e.g. via ldconfig), it appears that this is a recorded implicit dependency which is encoded in the library itself. The only way to remove such an implicit dependency is to rebuild the library (e.g. libzmq.so) with different options.

If the persons who delivered the compilers to you expected that the C++ library was truely reusable, then they would not have have put everything under /opt/gcc-foo directories (also suggesting that these directories are removable). Instead they would have put the C++ run-time libraries in a standard system location. For example, under Ubuntu Linux, I see that libstdc++.so.6 is at /usr/lib/x86_64-linux-gnu/libstdc++.so.6 which is a common system directory.

As far as I am aware, there is no option to request that libtool not perform the full linkage that it does. A common work-around is to remove the ".la" files that libtool produces and installs.

It is possible that GCC itself is pre-programmed (e.g. via the spec file) to record this information when it links with the C++ standard library.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]