Given we're strongly against bundling libraries, not to mention the resulting build time, I don't really get why we default to using bundled LLVM.
It's not only disabled by default, it's also stable-masked. There are multiple reasons: 1) Internal copy is often a bit older than system one. Currently it's llvm9. And this is what's tested. 2) Patching of rust often required to support new versions of LLVM. It can be quite problematic. 3) Rust's llvm copy contains number of codegen fixes / backports from llvm trunk. 4) with system-llvm users loose a bit of functionality. For example: > rustc --print target-cpus > Available CPUs for this target: > native - Select the CPU of the current host (currently pwr9). > 440 > 450 > 601 > ... ^ this and some other tight llvm integration only possible and works if using internal llvm. on [system-llvm] rust this command will refuse to print CPUs. 5) It simply fails sometimes at codegen. It used to fail more often, we haven't encountered it for quite some time, thanks for upstream testing and local patching. 6) Build-wise, only libLLVM.so. sometimes LLD, but only for wasm. We don't install full llvm suite. 7) Tests sometimes fail with system-llvm. Testsuite is not enabled for users yet, needs more work filtering out meaningful tests and disabling what's useless for end-user. Last 6 month there has been way less bug reports related to system-llvm, but I still think it's should not be the default. Yeah, bundling sucks, but in this case we loose functionality and maybe stability if we use system version. It's not like they bundle exact copy and results are exactly the same.
The rust llvm tends to have a number of fixes applied, we could try harder to have upstream to take fixes (like the one about the target list) and/or decide to carry them ourselves in our normal llvm.
another point just happened on gentoo-dev rust, built with system-llvm, where llvm had NVPTX target enabled. later, user disables NVPTX and rebuilds llvm. llvm abi breaks and rust can no longer be launched rustc --print sysroot rustc: symbol lookup error: /usr/lib/rust/lib/librustc_driver-f8cd10506120c696.so: undefined symbol: LLVMInitializeNVPTXTargetInfo, version LLVM_12 user can rebuild llvm again with NVPTX, but will not be able to get rid of abi breakage in rust, if using system-bootstrap. because as soon as abi breaks rust stops working, and no longer able to rebuild itself. one of the ways to break the cycle is: emerge rust without system-llvm, re-emerge llvm without NVPTX, re-emerge rust with system-llvm. nasty UX.
Maybe make rustc load those symbols dynamically?
It's interesting how every justification for static linking is based on bad code.
Isn't it is a same for gcc if rebuild gcc dependency to ABI incompatible?
I have problems compiling >=dev-lang/rust-1.51.0-r2 in a gcc-11.1.0-r1 based chroot, when the system-llvm flag is unmasked and enabled. There is no actuall error message, for some reason it takes really long to build the package. So much longer, that I stopped with CTRL+C when it was 100% over the time it takes to do the same task on gcc-9 based system. Without unmasking and thus using the system-llvm flag, there is no problem with emerging dev-lang/rust.
