On 13 April 2017 at 12:40, Jonathan Wakely wrote: > On 13 April 2017 at 02:16, Guilherme Quentel Melo wrote: >> Hi, >> >> In an attempt to run an OpenGL application on CentOS 7 I've bumped on >> an "invalid pointer" crash in libstdc++. Details can be seen on this >> bug report: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1417663 >> >> Sorry for posting an external link, but in summary on CentOS 7 mesa is >> compiled against a specific llvm version which then is statically >> linked to libstdc++ (gcc 4.8.5). >> >> But my application uses a more recent gcc (5.4.0) and I ship a >> launcher script which always choose to run with the newest version. >> This approach works pretty well among many Linux distributions, but >> not in this case where a system library that I need is statically >> linked to libstdc++. >> >> So before digging into more details I would like to know: >> >> Is mixing a system library statically linked to libstdc++ with an >> executable dynamically linked to a newer libstdc++ expected to work at >> all? > > It depends. > > It's not supported to mix C++11 code compiled with 4.x and GCC 5+, in > any way, whether linking dynamically or statically. > > If you're only using C++98 (and of course only using the old COW > std::string in the code compiled with GCC 5+) then I think it should > work OK, because the definitions of the std::string member functions > should be compatible. Comparing the code from GCC 4.8 and 5 I don't > see any incompatibilities, but maybe I missed something. This of course assumes both GCC versions are configured to be compatible, i.e. you're not using --enable-fully-dynamic-string for your GCC 5 build, which creates a libstdc++.so that is not compatible with the CentOS system one.