[Bug c++/68479] New: Dynamic loading multiple shared libraries with identical static libstdc++ breaks streams

["dd0t at users dot sourceforge.net" <gcc-bugzilla at gcc dot gnu dot org>]

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