This partially reverts c7b3a91017d26266d7556b1ac7c49b06f0109b91. Having
libclang.so with a different SONAME than the other LLVM libraries was
causing a lot of confusion for users. Also, this change did not really
acheive it's purpose of allowing apps to use newer versions of
libclang.so without rebuilding, because a new version of libclang.so
requires a new version of libLLVM.so, which does not have a stable ABI.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for the ping. It's unfortunate that this didn't work out as intended. It's certainly fine though (for our purposes) to go back to the way things were before.
LGTM. I have seen multiple reports that distributors found this behavior change surprising.
I agree that having this more complex symbol versioning with libclang.so probably doesn't improve things a lot since libclang uses LLVM and the LLVM lib doesn't have API/ABI stability.
Basically yes, thank you! I'd still be more precise and say "soversion" rather than "soname", but otherwise OK.
As a downstream packager of libclang, I really like the SONAME not changing in libclang. It makes it possible for us to package things like qt that depend on libclang, but not have to rebuild qt for every major revision of LLVM.
It's not clear to me what the reason for removing this is. Can someone help me understand why this useful feature was removed?
Too many users have complained that an unchanged soname may suggest some bugs in the build system.
Maybe this should be a cmake option that is off by default and I can turn it for my builds?
I proposed something along those lines in https://discourse.llvm.org/t/rationale-for-removing-versioned-libclang-middle-ground-to-keep-it-behind-option/64410
Also, this change did not really acheive it's purpose of allowing apps to use newer versions of libclang.so without rebuilding, because a new version of libclang.so requires a new version of libLLVM.so, which does not have a stable ABI.
Could you elaborate on this? If an application uses only libclang.so, and that is updated to a newer version using a newer libLLVM.so, why would the application need to be rebuilt? Isn't the C API self-contained?
It was a bit tough to decouple libclang.so packaging-wise, but we released it like that already and reverting now seems to just obsolete efforts that had already happened.
Could you elaborate on this?
Sure. If an application links to libclang.so when the application is being built, the application will hardcode libclang.so.13 in it and will look for it.
When the SONAME changes to libclang.so.15 in LLVM 15, the application will not be able to use the libclang from LLVM 15 unless the
application was rebuilt with libclang.so in LLVM 15.
That's the problem after this change, but what was the problem before the change? The commit message (where my quote is from) suggests this wouldn't have worked even if we stayed at libclang.so.13 in LLVM 15.