[...]
Ideally, libunwind-16 and libunwind-19 can be installed in parallel. Likewise, libc++1-16 and libc++1-19. Since llvm 16 is being dropped from sid/trixie, it would be good to get this fixed in llvm 19 and also future major versions. We've already worked around the 16 -> 19 upgrade issue for chromium by switching to (temporarily?) linking against libstdc++.
Chromium upstream is no longer allowing libstdc++ linkage after chromium 138, so this has now become a priority.
Proposal:Assuming that newer versions of libc++* and libunwind-* symbols are backwards compatible with older versions, it would be nice to rename the packages based on their SONAMEs. For example, libc++1-19 becomes libc++1 (with libc++1 binary package being removed from the llvm-defaults source package), and when a package builds against libc++-dev the resulting binary package gets a dep of (libc++1 >= 1:19.1.5). That way, if some other package links against libc++* from llvm20 while chromium links against libc++* from llvm19, both packages can use libc++* from llvm20.
I've decided against this scheme because it requires coordination with the llvm-defaults package, and because it wouldn't allow packages to link against specific versions of libc++ if needed. So instead, like libclang1 and its friends, I'm leaning towards embedding @LLVM_VERSION@ in the SONAME.
I'm not sure why libclang1-20 is using an SONAME of "libclang-20.so.20", while libllvm20's SONAME is "libLLVM.so.20.1", but for libc++1-20 I'm leaning towards doing something like "libc++-20.so.1". Does that make sense? Or would you prefer libc++-20.so.20? I would also be changing the SONAMEs for the libc++abi1-20 and libunwind-20 packages.
Since trixie is frozen for transitions and llvm-toolchain-20 is still only in experimental, I plan to start by targeting -20 to minimize any kind of breakage from packages that might have already built against libc++. Once that's complete, I'll coordinate with the SRMs, and firefox & rust folks to update the bookworm llvm-toolchain-19 package to use the new SONAME (I don't think any of them are dynamically linking against it, but just in case). Trixie will require a separate release-team discussion.
OpenPGP_signature.asc
Description: OpenPGP digital signature
