What is the magic here?
This is basically the magic of ELF character versioning. The best link I've seen on this is How to write shared libraries by Ulrich Drepper, in particular section 3.
How can they provide gcc 4.4.7, which refers to an older version of libstdc ++? I thought it was impossible.
LibstdC ++ developers are wary of ABI compatibility. This makes it easy enough to understand what new characters are introduced between two different versions of libstdc ++.
Looking at the libstdC ++ ABI compatibility page, you can see that GCC 4.1 libstdC ++ has GLIBCXX_3.4.8 and the stock (FSF release) of GCC 4.4 has GLIBCXX_3.4.13. You can then look at the libstdC ++ scripts to see what characters were added between the two versions.
A more empirical route for viewing character versions is to use a tool such as readelf. For instance. on my Ubuntu system readelf --dyn-syms --wide /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | c++filt readelf --dyn-syms --wide /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | c++filt shows output similar to this (just a few short lines selected):
223: 000000000006dbe0 2121 FUNC GLOBAL DEFAULT 12 std::ios_base::Init::Init()@@GLIBCXX_3.4 ... 226: 00000000002ed920 1 OBJECT GLOBAL DEFAULT 27 std:: adopt_lock@ @GLIBCXX_3.4.11
Note the character versions at the end of the character name after @@ .
what is this stdc ++ _ library?
Combining the points in the paragraph above, stdC ++ _ nonshared is a static library that contains characters that would be in the libstdC ++ directory. so.6.0.13, but not in libstdC ++. so.6.0.8.
I did not know that the .so file could contain this text. Who parses it (dynamic linker, I think), what are its specifications and consequences?
The regular linker parses this, not the runtime linker. See the binutils documentation for INPUT in the linker script . As a result, the link to this special libstdc ++. So.6.0.13 will force the linker to dynamically bind to libstdC ++. So.6.0.8 and statically reference a library that contains additional characters.
The disadvantage of this is that an application compiled in this way will be slightly more bloated than the same application, which is dynamically linked only to the libstdC ++ package. so.6.0.13, which contains all the necessary characters. The surface is that functions from the new standard library can be used on standard installations of older systems, without independent software vendors who need to send their own copies of libstdC ++.
How far can this magic go? Can I use gcc4.7 with libstdc ++ 6.0.3? What is the compatibility spectrum
Now that you know what magic is, you can probably appreciate that this version of GCC 4.4 you have a special version made only for Centos 5 (well, originally Red Hat 5). You can probably create GCC 4.7 that will generate binaries that only require libstdc ++ 6.0.3, but that will require a non-trivial number of corrections to your GCC tree to put the correct characters in stdc ++ _ nonshared.a. You can at least look at the sources for RPC gcc44 to see how Red Hat works there.
Red Hat seems to continue this approach with the Red Hat Developer Toolset . At the time of writing, GCC 4.8.1 is the latest compiler that can create binaries for EL5, which still only requires libstdC ++. So.6.0.8 for installation on the target system. This is great for developers who want to write in C ++ 11, but should be able to deploy to EL5 or EL6.