Suspicious change to `libc++-20-dev` dependency on `libc++*`

[firewave]

Starting today I was seeing this installing the packages from apt.llvm.org

The following packages were automatically installed and are no longer required:
  libc++1-20 libc++abi1-20 libunwind-20
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  libc++1 libc++abi1 libunwind
The following packages will be upgraded:
  clang-20 clang-21 clang-tidy-20 clang-tidy-21 clang-tools-20 clang-tools-21 clangd-20 libc++-20-dev libc++abi-20-dev
  libclang-20-dev libclang-21-dev libclang-common-20-dev libclang-common-21-dev libclang-cpp20 libclang-cpp21
  libclang-rt-20-dev libclang-rt-21-dev libclang1-20 libclang1-21 liblldb-20 libllvm20 libllvm21 libunwind-20-dev
  lld-20 lldb-20 llvm-20 llvm-20-dev llvm-20-linker-tools llvm-20-runtime llvm-20-tools llvm-21 llvm-21-dev
  llvm-21-linker-tools llvm-21-runtime llvm-21-tools python3-lldb-20

The current system shows the following dependencies

$ apt-cache rdepends libc++1-20 libc++abi1-20 libunwind-20
libc++1-20
Reverse Depends:
  libc++-20-dev
libc++abi1-20
Reverse Depends:
  libc++1-20
  libc++abi-20-dev
libunwind-20
Reverse Depends:
  libc++1-20
  libunwind-20-dev
  libc++abi1-20

$ apt-cache show libc++-20-dev
Package: libc++-20-dev
Source: llvm-toolchain-20
Version: 1:20.1.7~++20250616065743+6146a88f6049-1~exp1~20250616065852.130
Architecture: amd64
Maintainer: LLVM Packaging Team <pkg-llvm-team@lists.alioth.debian.org>
Installed-Size: 20397
Depends: libc++1 (= 1:20.1.7~++20250616065743+6146a88f6049-1~exp1~20250616065852.130), libc++abi-20-dev (= 1:20.1.7~++20250616065743+6146a88f6049-1~exp1~20250616065852.130), libunwind-20-dev

Looks like the version was accidentally dropped from the dependency for the newer package:

$ apt-cache depends libc++-20-dev
libc++-20-dev
  Depends: libc++1
  Depends: libc++abi-20-dev
  Depends: libunwind-20-dev

[sylvestre]

@dilinger made some changes recently on this

[dilinger]

It's not accidental. Since we're guaranteed a stable ABI, we can drop the major version from the package name (see #142759 for more on that). Currently we've only made the change to llvm-toolchain-20, but I expect we'll update -21+ once this gets a bit more testing. Things that dynamically link against libc++.so.1 can simply depend upon libc++1 >= $version rather than, eg, libc++1-20 which cannot be installed next to libc++1-21. This allows multiple packages to dynamically link against libc++ without conflict; otherwise, chromium might depend upon libc++1-21 while rustc might depend upon libc++1-19, and both packages couldn't be installed simultaneously.

[sylvestre]

@firewave what do you think about this ? :)

[firewave]

That makes sense. But only in terms of a distro. In the case of apt.llvm.org that would actually defeat the purpose. Even though the ABI is guaranteed the behavior of the implementation isn't. So instead of getting the implementation of the version you installed you will be getting the vendor one (in my case that would version 10).

[dilinger]

If you're relying on a specific version behavior, and the llvm version in your distribution is newer than the version you're getting from apt.llvm.org, then I'd suggest that you use pinning rather than relying on package names. Something in /etc/apt/preferences (or if automatically created by llvm.sh, /etc/apt/preferences.d/llvm) like,

Package: *
Pin: origin apt.llvm.org
Pin-Priority: 900

See apt pinning in https://wiki.debian.org/AptConfiguration

[firewave]

My distro is actually much older than the one I install from apt.llvm.org. I am not aware of pinning and have to look into it.

The problem is that this changed the default behavior of apt.llvm.org with people expecting that it will actually use the implementation of the version you installed.

I am quite surprised this hasn't broken things for people - but that is possibly because most people use the default standard library which will still be libstdc++ and this related to libc++ only.

I wonder though if there is a potential future issue here if sanitized libraries are ever added as those are probably not ABI safe.

[firewave]

CC'ing @philnik777 @ldionne as I am a layman (which is already a gross overstatement) in this area.

[dilinger]

The problem is that this changed the default behavior of apt.llvm.org with people expecting that it will actually use the implementation of the version you installed.

I am quite surprised this hasn't broken things for people - but that is possibly because most people use the default standard library which will still be libstdc++ and this related to libc++ only.

This should* only change behavior for people building against newer versions of llvm. If you're using llvm-19 (or llvm-10, or whatever older versions), then that should continue to depend upon libc++1-19 and packages/binaries you provide should maintain that dependency. It's only for newer versions of llvm (>= 20) that the libc++1 will be depended upon; and that's only for dynamic linking.

That, combined with the previous challenges of dynamically linking libc++, is likely why this change hasn't broken things for people.

• with the caveat that I still need to test a bunch of corner cases related to the llvm-defaults package and upgrades, but that's more of a debian issue than apt.llvm.org issue. It looks like apt.llvm.org's llvm-defaults package doesn't even have libc++1/libunwind.

[philnik777]

I'm not sure I understand the concern. We're guaranteeing that the dylib continues to work as expected for binaries compiled against older versions, so I don't know why you would ever care which exact version is used as long as it's not older than the one you compiled against.