Comment # 21 on bug 1221183 from Aaron Puchert

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