Comment # 23 on bug 1221183 from Richard Biener

(In reply to Richard Biener from comment #22)
> (In reply to Aaron Puchert from comment #21)
> [...]
> > (In reply to Franz Sirl from comment #20)
> > > The specific problem is the global object
> > > clang::format::FormatTokenLexer::CSharpAttributeTargets from libclang-cpp
> > > has global constructors/destructors. The object seemingly is merged by the
> > > shared loader when 2 libclang-cpp with different versions are loaded.
> > 
> > That would surprise me. I think that copy relocations allow the linking
> > application to interpose the library variable with their own copy, but this
> > should still be subject to symbol versioning. At least I'd hope so.
> 
> This should work for the symbols in the libraries themselves.  I'm not sure
> how users go though since two versions are likely pulled in only indirectly,
> aka App X uses LLVM15 and library Y which uses LLVM13.  Iff both App X and
> library Y instantiate a "LLVM typed object/template" then those
> instantiations
> will not have a symbol version and those could be subject to false
> interposition (usually COMDAT handling).  The solution would be for
> library Y to better constrain what it exports of course, but that's not the
> rule in the C++ world unfortunately.

Oh, and "naming" the library differently doesn't help of course, the library
SONAME is not part of instantiated objects.  The problem here is really the
C++ ODR.  GNU C++ offers kind-of a workaround via ABI-tags, but I don't think
they are widely used besides in GCCs C++ standard library.