C++ plugin .so fails to load inside a host app that bundles an older libstdc++ (GLIBCXX_x.y.z not found)

Symptom: a C++ shared-object plugin built with a newer GCC (e.g. GCC 11, needing GLIBCXX_3.4.29) works with one release of a host application but fails to load in another, older release. The failure appears at plugin load or link time and comes before any of the plugin's code runs. The cause is that the older host ships its own libstdc++.so.6 in its install tree and puts it first on the library path, so the plugin resolves against that older runtime, not the system one.

Diagnose: - objdump -T plugin.so | grep GLIBCXX_ | sort -u lists the versions the plugin needs. - strings <host>/lib/libstdc++.so.6 | grep GLIBCXX_ shows what the bundled copy provides.

Fixes, safest first: 1. Link the plugin with -static-libstdc++ -static-libgcc, export only a C ABI, and hide the other symbols with -fvisibility=hidden or a version script, so the static runtime does not interpose on the host's C++. 2. Build with a toolchain no newer than the oldest host's bundled runtime.

Avoid a global LD_PRELOAD of a newer libstdc++ or swapping the host's copy: that changes the host's own behaviour and is hard to support.

Also: a failure at this stage says nothing about the plugin API itself. Record it as a runtime packaging failure, not a functional result.