Pulling llvm 15.0.4 from apt.llvm.org, I see static libraries that contain bitcode instead of machine code. These will only link with llvm’s linker, not the system linker, and it makes statically linking something against llvm take a long time (I killed it after 5 mins). This is going to break a lot of workflows. Hopefully it was inadvertent?
For reference, homebrew ran into the same issue and after some spirited discussion with downstream projects fixed it in the following way: llvm: convert bitcode in static archives to object code by carlocab · Pull Request #112154 · Homebrew/homebrew-core · GitHub
Also, putting bitcode into static libraries constraints you to using a specific version of the linker (IIUC, bitcode is never promised to work correctly with any version of the tooling other than the version that created it)… this seems like a very problematic decision for long-term archival purposes.
This sounds like an accident due to building with (Thin)LTO, not an intentional decision.
Chrome’s toolchain ran into the same thing where we can’t use the libraries from the official clang package because we build it with ThinLTO. We have to use libraries from a previous stage for other LLVM users.
I don’t think there’s an in-tree way of doing this nicely in one build. We’d benefit from a nicer way in LLVM’s CMake machinery of having the release libraries be non-bitcode libraries.
The APT packages are meant to be doing the same thing that Homebrew is doing:
Maybe you’re picking up an older version? Not sure why (or where) you’re getting 15.0.4, though, since I don’t think that’s been released anywhere.
I’m getting it directly from apt.llvm.org via
bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"
Sounds like debian will be fine, but hopefully I’m acting as a canary here and alerting people to the issue before it causes problems elsewhere.
yeah, my bad, it wasn’t supposed to be pushed. There is indeed an issue.
sorry. I reverted the change and retriggered the builds.