https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68479
Bug ID: 68479 Summary: Dynamic loading multiple shared libraries with identical static libstdc++ breaks streams Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dd0t at users dot sourceforge.net Target Milestone: --- Created attachment 36802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36802&action=edit Minimal reproducer Loading two shared libraries compiled with identical flags and the same compiler into the same process using dlopen breaks the use of std::stringstream (and probably more) when they link libstdc++ statically using "-static-libstdc++". This was reproducible for me using gcc 5.1.1 (old abi), gcc 5.2.1 (Ubuntu 15.10, new abi) and gcc-5-branch (r230629, new abi) with the attached minimal reproducer and did not occur in gcc 4.9. The reproducer consists of a small C program (no C++ dependencies) which uses dlopen to load two practically identical .so's which perform a trivial stringstream operation. The reproducer .so's do this operation on-load but that's not relevant for the issue. I'm unsure on whether this kind of breakage is expected or if this is an actual bug with libstdc++. I originally encountered it when loading multiple .so's using System.loadLibrary into a JVM. Below is the README of the reproducer with some more information: Requires: - g++-5 - Some gcc (5 is fine) How to reproduce: - Run ./build.sh - Run ./test Expected: $ ./test dlopen x.so X0 dlopen y.so X1 What happens: $ ./test dlopen x.so X0 dlopen y.so terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast Aborted (core dumped) Does not occur when: * Linking libstdc++ dynamically * Not dynloading the .so's but instead using gcc to link them in * LD_PRELOAD'ing libstdc++ * Building the .so's with gcc 4.9 instead of 5.1.1