Bug#1089933: llvm-toolchain-19: allow multiple version of libc++* and libunwind* to be installed at the same time

[Andres Salomon]

Package: llvm-toolchain-19
Version: 1:19.1.4-1~deb12u1
Control: affects -1 chromium

Please make it so that libc++1-19 and subsequently ABI-versioned 
packages (eg, libc++1-20) can be installed in parallel.

Rationale:

A few months ago, chromium switched to linking against (llvm's) libc++ 
instead of (gcc's) libstdc++.  At the time, we were building on bookworm 
using llvm 16. Because we are linking dynamically against libc++ (I'm 
told that linking statically results in a segfault on armhf, by someone 
who has tested it), the resulting chromium binary package has 
dependencies upon libc++1-16, libc++abi1-16, and libunwind-16.

Chromium then switched to llvm 19, which resulted in dependencies upon 
libc++1-19, libc++abi1-19, and libunwind-19. Because they contain the 
same files (eg, all libunwind-* amd64 packages contain 
/usr/lib/x86_64-linux-gnu/libunwind.so.1.0), the -16 and -19 versions of 
the libraries conflict. This makes upgrading problematic, as various 
package-related tooling will then either refuse to upgrade chromium. 
'apt upgrade' and gnome-software will simply report the conflicts, 
requiring an 'apt dist-upgrade' to get apt to remove libunwind-16 and 
install libunwind-19. The conflict also means that multiple packages on 
a system cannot be (dynamically) linked against multiple versions of llvm.

Request:

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

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.

If they're not backwards compatible, I'm not really sure what to do. It 
feels like the conflicting symlinks that are currently in libc++1-19 
should instead be in llvm-default's libc++1 (which would allow the 
conflicts to be dropped from libc++1-19), but we're not going to 
backport llvm-defaults when we do a stable backport of llvm-toolchain-*. 
Maybe that's good enough, though, and packages that want to use a 
non-default llvm simply build using -Wl,-rpath,/usr/lib/llvm-19/lib ?

If anyone else has ideas, I'd love to hear them. I don't know how long 
chromium will stick with libstdc++, and switching away from libc++ only 
automatically cleans up older packages of libc++* during 
unattended-upgrades but not via gnome-software or 'apt upgrade'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-llvm-team/attachments/20241214/eb729dba/attachment.sig>