Anyone know how to be sure that ICC 13's C++11 support isn't a problem on older Linux systems?
ICC 13 on Linux uses the available version of GCC to supply libstdc and libstdc++. On CentOS/RHEL 6.4, the GCC version is 4.4.7. The associated version of libstdc++ lacks some C++11 features I'd like to use, but they're present in GCC 4.7.2.
To get access to those features on my CentOS 6.4 (64-bit) system, I installed and enabled the CentOS port of the "devtoolset-1.1" SCL. The provided version of GCC 4.7.2 seems to work on its own, and when I'm compiling my C++11 code using Intel's compiler.
My problem is any program I build with ICC is still dynamically linking to the older, system-wide version of libstdc++.so. That is, when I run "ldd" on my ICC-generated programs, one of the results is "libstdc++.so.6 => /usr/lib64/libstdc++.so.6". I'm concerned that this apparent mismatch between needing the newest GCC at compile time, but dynamically linking to the the older GCC at runtime (according to ldd) is setting me up for some hard-to-figure-out problems at runtime.
Does anyone know if this is a real problem? And if so, how do you get around it?
Adding the apporpriate directory under "/opt/centos/devtoolset-1.1/..." did not seem to fix this. I could be wrong, but perhaps that's because devtoolset-1.1 provides a "libstdc++.so" file, but not "libstdc++.so.6"?
You're right that libstdc++ may not be fully compatible between g++ 4.4 and g++ 4.7.
Some of your options appear to be:
1) Test your application thoroughly while running against the older libstdc++
2) require that your application be run with the correct gcc .so library coming first on library search path
3) static link against libstdc++ (test to see if there is a problem with varying libgcc.so)
Thanks Tim. Do you know if anyone on the compiler team has looked into all this and done a write-up?
I assume they'd have throught through the various ways things might go wrong when depending on someone else's version of libc.so / libstdc++.so.