Comment # 22 on bug 1221183 from Richard Biener

(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.