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

[Bob Friesenhahn]

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