Page MenuHomePhabricator

libclang.so: Make SONAME the same as LLVM version
ClosedPublic

Authored by tstellar on Jul 5 2022, 1:56 PM.

Details

Summary

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.

Diff Detail

Event Timeline

tstellar created this revision.Jul 5 2022, 1:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 5 2022, 1:56 PM
tstellar requested review of this revision.Jul 5 2022, 1:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 5 2022, 1:56 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

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.

MaskRay accepted this revision.EditedJul 6 2022, 12:37 AM

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.

This revision is now accepted and ready to land.Jul 6 2022, 12:37 AM

Forgot to mention it before: would be good to note this in the release notes

tstellar updated this revision to Diff 444843.Jul 14 2022, 4:43 PM

Add release note.

@h-vetinari Does the release note look OK?

@h-vetinari Does the release note look OK?

Basically yes, thank you! I'd still be more precise and say "soversion" rather than "soname", but otherwise OK.

@h-vetinari Does the release note look OK?

Basically yes, thank you! I'd still be more precise and say "soversion" rather than "soname", but otherwise OK.

OK, I'll fix that when I commit it.

This revision was automatically updated to reflect the committed changes.
isuruf added a subscriber: isuruf.Thu, Aug 11, 6:47 AM

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?

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?

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.

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.