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?


  • 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
  • Where do you see that link against 6.0.8?
    – Nils
    Commented Jun 5, 2013 at 13:10
  • @Nils: because I don't get any symbols from 6.0.13 in a test executable I use to reveal 6.0.13 symbols. In fact, I get them when I compile with gcc 4.4 on another platform. When I compile on centos, all the symbols my executable binds toward are the ones in the ABI for gcc 6.0.3. Commented Jun 7, 2013 at 17:10
  • see this answer on stackoverflow; is possible to use an old libstdc++ and an additional static lib (libstdc++_nonshared) to provide more recent functionality
    – tcris
    Commented Jun 4, 2014 at 11:48

1 Answer 1


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


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 <[email protected]> 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.

  • interesting. so it's technically possible, but only some special circumstances allow me to. Meaning that if I want to use gcc 4.7 and produce something compatibile toward an old libstdc++ ABI, the only way would be to patch the library itself as redhat did. Commented Jun 7, 2013 at 17:07
  • 1
    by the way, your answer is good, but I am also trying to understand the points I raised about the text file and so on. It's not only the issue in itself, but also the need to learn more about this topic. Commented Jun 7, 2013 at 17:11
  • @StefanoBorini I am not a programmer - perhaps that part of your question can be answered on stackoverflow.
    – Nils
    Commented Jun 7, 2013 at 19:55
  • thanks. I asked the same question there as well, but I received no answer. Apparently, it's not something a lot of people know about. Commented Jun 7, 2013 at 20:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .