Risks of different GCC versions at link / run time?
I'm using Intel's C++ compiler, which on Linux relies on the GNU-supplied libc.so and libstdc++.so.
Here's my problem. To have access to some of the newest C++11 features, I need to use the libstdc++ which ships with GCC 4.7 or higher. But I'm stuck using CentOS 6.4.
On CentOS 6.4, the native version of GCC is 4.4. But using a RedHat thing called "SCL" and a package named "devtoolset-1.1", I'm able to get GCC 4.7 installed under "/opt".
I set things up to be using GCC 4.7 in the manner mentioned above, I can use the newer C++11 features.
So here's my question: If a user runs my program with only the GCC 4.4 versions of libc.so / libstdc++.so in the library path, is there a risk that my program will have bugs due to some mismatch between the 4.4 and 4.7 versions of those libraries?
If there is a potential problem, can I work around it by statically linking in GCC 4.7's versions of libc and libstdc++? Or is that setting myself up for other problems if/when other libraries that my code dynamically loads pick up the older libc / libstdc++ supplied by the system-wide GCC 4.4 package?
Answer
As Praetorian pointed out in the comments below, the use of devtoolset actually solves the problem I originally described in this answer. I've corrected the answer.
is there a risk that my program will have bugs due to some mismatch between the 4.4 and 4.7 versions of those libraries?
Yes. Linking against a newer libstdc++.so and then trying to run against and older one is 100% not supported. If any object in your program or any libraries it uses is compiled with GCC 4.7 and linked to the libstdc++.so from 4.7 then you need to use the libstdc++.so from 4.7 (or newer) at runtime. It probably won't even run, but if it does there may be silent bugs due to incompatibilities. But that's not a problem in your case, because you're not linking to GCC 4.7's libstdc++.so, see below.
can I work around it by statically linking in GCC 4.7's versions of libc and libstdc++?
1) You would only need to do that for libstdc++, because there is no such thing as "GCC 4.7's version of libc". Glibc is a completely separate project from GCC. When you are using GCC 4.7 you're not using a different libc, you're still using the system libc from CentOS 6.4. (As an aside, be aware that statically linking glibc is strongly advised against by the glibc maintainers, and some features of glibc will not work when statically linked.)
2) Statically linking libstdc++ would work around the problem, but you don't need to, because that's what the Red Hat Developer Toolset (devtoolset) does for you anyway. The whole point of devtoolset is that it allows you to use a newer GCC and newer libstdc++ but without creating any run-time dependencies on the newer libstdc++ library. The compiled executables only need the system version of libstdc++.so that is always present on RHEL/CentOS, even systems without devtoolset installed. (What devtoolset does is package all the new libstdc++ features in a static library, called libstdc++_nonshared.a so that all the pieces not present in the system libstdc++.so get statically linked in, and everything else will come from the system libstdc++.so).
If you weren't using devtoolset then another option instead of statically linking libstdc++ would be to ship the newer libstdc++.so with your code and ensure it is found first (e.g. by linking your code with an RPATH that refers to the newer libstdc++.so). But with devtoolset that's not necessary.
Or is that setting myself up for other problems if/when other libraries that my code dynamically loads pick up the older libc / libstdc++ supplied by the system-wide GCC 4.4 package?
There will be no such problems when using devtoolset, because you're always using the older libstdc++, and so there is never a conflict.