Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 735154 - dev-lang/rust USE=system-llvm should be enabled by default
Summary: dev-lang/rust USE=system-llvm should be enabled by default
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo Rust Project
Depends on:
Reported: 2020-08-02 06:43 UTC by Michał Górny
Modified: 2024-02-14 10:26 UTC (History)
18 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-08-02 06:43:49 UTC
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.
Comment 1 Georgy Yakovlev archtester gentoo-dev 2020-08-02 21:33:06 UTC
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 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.
Comment 2 Luca Barbato gentoo-dev 2020-08-03 09:12:43 UTC
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.
Comment 3 Georgy Yakovlev archtester gentoo-dev 2021-06-01 22:03:24 UTC
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/ 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.
Comment 4 Oleg 2021-06-02 05:37:02 UTC
Maybe make rustc load those symbols dynamically?
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-06-02 08:05:19 UTC
It's interesting how every justification for static linking is based on bad code.
Comment 6 Oleg 2021-06-02 08:20:26 UTC
Isn't it is a same for gcc if rebuild gcc dependency to ABI incompatible?
Comment 7 tt_1 2021-07-01 05:53:29 UTC
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.