4

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
Improve this question
3
  • Where do you see that link against 6.0.8?
    – Nils
    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.
    – Stefano Borini
    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
    Jun 4, 2014 at 11:48

1 Answer 1

Reset to default
4
+50

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

Improve this answer
4
  • 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.
    – Stefano Borini
    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.
    – Stefano Borini
    Jun 7, 2013 at 17:11
  • @StefanoBorini I am not a programmer - perhaps that part of your question can be answered on stackoverflow.
    – Nils
    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.
    – Stefano Borini
    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 .