Binary compatibility between an old static libstdc++ and a new dynamic one

Jonathan Wakely jwakely.gcc@gmail.com
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:
>> 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.



More information about the Gcc-help mailing list