[Bug 1221183] Upgrade problems with clang-cpp
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1221183
https://bugzilla.suse.com/show_bug.cgi?id=1221183#c23
--- Comment #23 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.
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. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com