libc++1-20 deb packages missing libc++.so.1 symlink

[jeroen]

On our llvm-20 CI shows errors that do not happen on the same CI for llvm-19:

libc++.so.1: cannot open shared object file: No such file or directory

Upon closer inspection it seems the file /usr/lib/x86_64-linux-gnu/libc++.so.1 is no longer there.

See file contents: https://packages.debian.org/experimental/amd64/libc++1-20/filelist

Compare with https://packages.debian.org/sid/amd64/libc++1-19/filelist

The same problem occurs with packages provided via deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-20 main

@sylvestre @dilinger from the llvm-toolchain-20 changelog

llvm-toolchain-20 (1:20.1.5-1~exp3) experimental; urgency=medium

  [ Andres Salomon ]
  * Add libcxx-soname.diff to modify SONAMES for libc++1-20, libc++abi1-20,
    and libuwind-20 to include the llvm major version (eg, 1.0.20 instead of
    1.0).
  * Remove conflicts/removes/provides from libc++1-20, libc++abi1-20, and
    libunwind-20 to allow parallel package installation with other major
    llvm versions (closes: #1089933).

[dilinger]

FYI, this was a debian-specific change made in order to allow various major versions of libc++ (and libc++abi/libunwind) to be installed side-by-side. See https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/165 and the linked debian bug for additional details.

I would love, however, for upstream to also adopt something like this patch. It seems like a fair number of C++ projects using llvm will target a specific major version (eg clang-16 or clang-20), and won't necessarily build against other versions. Producing binaries that link against a specific major version (as dictated by the SONAME) would be helpful in allowing people to do shared linking against libc++ instead of statically linking. At the moment, two packages linking against different major versions of libc++ would not be able to be installed because libc++.so.1 would be part of both packages. This is somewhat of a debian packaging quirk, but also I'm not convinced that having a never-changing SONAME of .so.1 while the C++ headers continue to evolve alongside C++ standards is a good policy.

[sylvestre]

@jeroen could you please provide a way for us to reproduce this issue? thanks

[jeroen]

This is somewhat of a debian packaging quirk, but also I'm not convinced that having a never-changing SONAME of .so.1 while the C++ headers continue to evolve alongside C++ standards is a good policy.

I think this is a bad idea. It means that applications built against libc++ will break for each upgrade of llvm or debian, unless you explicilty keep multiple old versions of libc++1 installed.

@jeroen could you please provide a way for us to reproduce this issue? thanks

Build anything on a system with clang < 20 and then run it on a system with clang-20.

[philnik777]

libc++ is generally ABI stable, so we should definitely not change the SO version every time. If we ever break the ABI we can and should change the version. This is exactly the same as libstdc++ handles it AFAIK.

[dilinger]

libc++ is generally ABI stable

Generally, or guaranteed? Part of the reason I went this route was due to the lack of clarity around this, and around the additional libraries (libc++abi and libunwind). If they are indeed guaranteed to be stable (and for Debian's purposes, that means newer version will never break existing binary interfaces - adding new binary interfaces is newer versions is of course fine), then I'll have a talk with @sylvestre about converting the package shared libs to look more like libstdc++.

I think this is a bad idea. It means that applications built against libc++ will break for each upgrade of llvm or debian, unless > you explicilty keep multiple old versions of libc++1 installed.

Well yes, being able to keep multiple old version of libc++ installed was the explicit goal here. Keeping around old versions until a package has been rebuilt against a newer ABI is something that Debian explicitly manages.

[philnik777]

libc++ is generally ABI stable

Generally, or guaranteed? Part of the reason I went this route was due to the lack of clarity around this, and around the additional libraries (libc++abi and libunwind). If they are indeed guaranteed to be stable (and for Debian's purposes, that means newer version will never break existing binary interfaces - adding new binary interfaces is newer versions is of course fine), then I'll have a talk with @sylvestre about converting the package shared libs to look more like libstdc++.

Guaranteed up to a point. If we believe that a break won't hurt any users we will take it sometimes. We definitely consider "this broke the ABI" a very good reason to revert (I don't think I've ever seen that though - we tend to be pretty good about rejecting ABI breaking patches). I've documented the guarantees more explicitly in #132615, so you might want to read through that.