Rationale for removing versioned libclang? --> Middle ground to keep it behind option?

Hi - In order to not delay 15.0.0-rc3 (and 15.0.0) I will merge the patch as proposed above to add a option to switch back to ABI version. I know that it’s not what some of you want (both because of fragmentation and that we should just commit to have ABI as SOVERSION) - but at this time and this late in the cycle I think it’s the most prudent thing to do. The patch was reverted on main because real world issues and while it was maybe done a bit hastily I don’t feel confident enough to revert the revert on the release branch only.

I hope that we can have this discussion before 16.0.0 branching and not have these questions come up late in the cycle so that there is enough time to discuss all of the sides and come to true consensus.

Thanks everyone that have given their feedback and contributed to the patch!

1 Like

I’m sorry for replying this late. From Gentoo’s perspective, libclang’s SONAME matching LLVM major version is better.

Normally, I wholeheartedly agree that SOVERSION should change only if ABI changed. However, LLVM is a fast moving target that breaks both ABI and API with every major release, and various software packages have major trouble following that. For this reason, we’re slotting LLVM and permitting multiple versions to be installed simultaneously. However, this implies that every LLVM and Clang version installed has its own libclang.so that links to the specific LLVM library.

Now, this generally means we’re going to end up with e.g.:

/usr/lib/llvm/13/lib64/libclang.so.13 (linking to libLLVM-13.so)
/usr/lib/llvm/14/lib64/libclang.so.13 (linking to libLLVM-14.so)

With both directories on ld.so search path, a software built against LLVM+Clang 13 may end up loading libLLVM-13.so and libLLVM-14.so simultaneously (one directly, the other via libclang.so.13). This just can’t work.

So unfortunate as it is, in our case libclang.so needs to have unique SOVERSION per LLVM version it links to.

Forward-linking this topic with renewed discussion in Unresolved issues from the LLVM 15.x release