CentOS 5.8 with gcc 4.4.7 links against libstdc++ 6.0.8. How is it possible

centosgcc

According to the gcc ABI policy, gcc 4.4.7 should depend on libstdc++ 6.0.13. As far as I understood, the compiler version and the libstdc++ version are deeply interrelated and can't be swapped, so it came to me as a surprise to discover the following facts:

CentOS 5.8 somehow manages to have a gcc44 package that links against 6.0.8, apparently coming with the default system (which is based on gcc-4.1.2)
that the libstdc++.so in the compiler directory (/usr/lib/gcc/x86_64-redhat-linux6E/4.4.7, where I expected to find a libstdc++-6.0.13) is not a link to a shared object of any sort, but a text file containing INPUT ( -lstdc++_nonshared /usr/lib64/libstdc++.so.6 )

What kind of magic is going on here?

Specifically:

How could they provide a gcc 4.4.7 that links against an older version of libstdc++? I thought it was not possible.
what is this stdc++_nonshared library?
I didn't know a .so file could contain that text. Who parses it (dynamic linker I guess) and what are its specifications and consequences?
How far can this magic go? Can I use gcc4.7 with libstdc++ 6.0.3? What is the spectrum of compatibility

Best Answer

If I do a rpm -q --requires gcc44 I see the following:

libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)

So there is no explicit version dependency to 6.0.13 in the rpm itselv.

As you found, the libstdc++.so.6 belongs to libstdc++-4.1.2-53.el5

This Version 4.1.2 has no real meaning in RedHat - it will contain backports for newer versions as well.

Look at this: rpm -q libstdc++ --changelog|more:

* Fri Mar 23 2012 Jakub Jelinek <jakub@redhat.com> 4.1.2-53.el5
- backport N2179 exception propagation support to improve
  gcc44 as well as Developer Toolset (#806275)

So obviously RedHat is actively patching this version so it is compatible with gcc44.

Related Solutions

Using ldconfig and ld.so.conf versus LD_LIBRARY_PATH

The solution to this is to add your library directories /usr/local/gcc-7.3.0/lib/ to /etc/ld.so.conf (or a file in /etc/ld.so.conf.d/) and run ldconfig or change users' shell profiles to override the systems' LD_LIBRARY_PATH/LD_RUN_PATH and add the individual */lib entries so that the linker can find the shared objects.

Once you start adding libraries, the complexity of maintaining this increases, so bear that in mind.

Another option that you have is to link all files from /usr/local/<library>/{bin,lib,include} into /usr/local/{bin,lib,include}. This greatly simplifies the ld.so.conf or LD_LIBRARY_PATH/LD_RUN_PATH although you will need to live with messy /usr/local/{bin,lib,include}.

The 'official' way to do this is to use the system's package manager and install the distribution's maintained versions of the libraries in the chosen locations (/usr/lib/, /lib, etc).

Centos 7 gcc 8 installation

Now devtools-8 is available and it's possible to use it by following commands:

yum install centos-release-scl
yum install devtoolset-8-gcc devtoolset-8-gcc-c++
scl enable devtoolset-8 -- bash

It's explained in a little more detail in this answer on StackOverflow: How to install GCC/G++ 8 on CentOS. And of course, if you need GFortran, you can install it in the same way - the package is devtoolset-8-gcc-gfortran.

Best Answer

Related Solutions

Using ldconfig and ld.so.conf versus LD_LIBRARY_PATH

Centos 7 gcc 8 installation

Related Question