[Top][All Lists]

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

Re: [EXTERNAL] Re: Unhelpful automatic 3rd-party library linkage

From: Bob Friesenhahn
Subject: Re: [EXTERNAL] Re: Unhelpful automatic 3rd-party library linkage
Date: Wed, 30 Jun 2021 08:38:00 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Tue, 29 Jun 2021, Oleg Smolsky wrote:
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?

Well, I want to claim that I am absolutely sure :) My understanding is that
there have been no ABI breaks in the GCC/libstdc++ ever (even noting the
5.x move to the Standard-compliant std::string). The general principle is
to let people/distros upgrade gcc/libstdc++ in the OS and let the old apps
continue running.

That is a good thing.

:) I am the person who maintains the compilers (installed into /opt/gcc-xx)
and 3rd-party libs (installed into /opt/3p) at our shop. I don't care to
update the system's compiler or libs as we don't use them at all. That is,
our build system uses our compiler and only links to the 3rd-party
dependencies from /opt.

Been there.  Done that. :-)

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

Right, I figured this very point out just a couple hours ago - the extra
flags/libs (along with the -lzmq transformation) come from the ".la" file.
I've rebuilt the lib, purged the file and things look good now for my build.

Could you shed some light on how this .la file is supposed to be used? I
see that it tries to be helpful by capturing the dependencies... but it
seems to destroy the standard `-lfoo` contract. IE it appears that it
reduces the level of abstraction needlessly for artifacts that are
distributed/stored. Is this ".la" thing meant only for build systems where
the whole tree is built from scratch at the same time?

It is true that the .la files encode all of the library dependencies which were current at the time. This is the most common complaint regarding libtool.

If this was not supported for static compilation, then static compilation would not be possible. Systems which do not support implicit dependencies in shared libraries also need this.

A model whereby libtool can know which explicit dependencies are desired and which should not not be recorded/replayed was never proposed.

As a result, it has become common for ".la" files to be deleted or edited (they are simple text files) in order to achieve the goals of binary distributions.

In your case it seems you are in complete control. You could put the most recent libstdc++ library in a common area and modify the ".la" files to refer to that one instead. If necessary provide a modifed GCC spec file to assure that the compiler itself does what you want while linking.

Unfortunately, existing libraries may have implicit dependencies baked into them which will not go away without rebuilding them.

Bob Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

reply via email to

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