Description
As of a few days ago, Arch Linux began shipping libxml2 2.14 (https://archlinux.org/packages/core/x86_64/libxml2/). This version notably breaks binary compatibility, changing the soname from libxml2.so.2 to libxml2.so.16 (reference in libxml2 NEWS file).
The version of lld that's shipped with the prebuilt binaries is dynamically linked to libxml2.so.2, and thus fails to run on these systems.
A related issue was filed at #113696. I figured it may be worth raising separately now that this is concretely affecting binary compatibility with actual distros, but apologies if this is too duplicative.
Note that I'm unsure of what level of cross-distro binary compatibility the project aims for. If this is out of scope, feel free to close. With that said, it seems like as distros update to follow the libxml2 upstream, this could become more of a concern.
One possible solution would be to statically link these libs for the release archives -- is that an option, or are there limitations that make this impossible/undesirable?
Looking more broadly broadly, lld seems to be dynamically linked against a few additional libraries, including liblzma and libicu as well, whereas clang links only to glibc and zlib. I'm unsure of what level of binary compatibility these libraries provide -- are future ABI breaks a concern at all?
Note also that a few other packaged tools seem to link to libxml2 as well, specifically:
lldb-server
lld
c-index-test
llvm-mt
lldb-dap
lldb
So if this is deemed an issue, might be useful to solve it in a way that works for these too.
I'd be happy to contribute any patches if needed, but I'm unsure where/how the build environment and flags for these prebuilt archives are set up.