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

[Jonathan Wakely]

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.