https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c21 --- Comment #21 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #16)
Unless llvm changed course and promised stable APIs and backward compatibility of course.
The C APIs (of LLVM and Clang) should be more or less stable, but the wider C++ APIs are not. (In reply to Franz Sirl from comment #19)
Wait? 2 different libclang-cpp and 2 different libLLVM will be loaded?
That can happen and shouldn't be an issue. Both libclang-cpp and libLLVM have versioned symbols and should be able to coexist in different versions in the same process, unless I'm missing something. (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.
the constructors/destructors are NOT merged, meaning that 2 constructors are run for the same object on library startup and 2 destructors are run on library shutdown.
That would be expected, the constructors and destructors are not visible to the linker as symbols, but simply as anonymous entries in .{init,fini}_array.
It seems LLVM realized that and reverted to building with LLVM-soversion == libclang-soversion by default, but the SUSE llvm builds override that with -DCLANG_FORCE_MATCHING_LIBCLANG_SOVERSION:BOOL=OFF. Should I file a bug against the LLVM component?
I'm not aware that this was the reason. What I've read from the posts is that some distributions were running into packaging issues because they have libclang and libclang-cpp in the same package. Or something like that. Having different versions of libclang-cpp or libLLVM in the same process is unfortunately hard to prevent once usage of the library gets more widespread. The API/ABI incompatibilities mean that different parts of the distribution will use different versions, some on the bleeding edge and others lagging behind. My understanding was that symbol versioning should have solved that. The only bug other than yours coming from a libclang incompatibility that I've seen since then was bug 1210176, but that was not an API/ABI incompatibility issue. Rather the user made assumptions about the naming of identifiers that were violated by the new version, but were actually never guaranteed. -- You are receiving this mail because: You are on the CC list for the bug.