Binary compatibility between an old static libstdc++ and a new dynamic one
Thu Apr 13 11:41:00 GMT 2017
On 13 April 2017 at 12:40, Jonathan Wakely wrote:
> On 13 April 2017 at 02:16, Guilherme Quentel Melo wrote:
>> 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:
>> 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
> 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.
More information about the Gcc-help