wuch-g2v
commented
6 months ago I'm not 100% but think that linking fails because is used hardcoded somewhere cc instead what is passed in $CC env variable.
Open wuch-g2v opened 6 months ago
wuch-g2v
commented
6 months ago I'm not 100% but think that linking fails because is used hardcoded somewhere cc instead what is passed in $CC env variable.
charliermarsh
commented
6 months ago What is the motivation for building from source?
charliermarsh
commented
6 months ago (Don't think we really do anything special here but @konstin would know better.)
wuch-g2v
commented
6 months ago What is the motivation for building from source?
ruff patches
.
.
MichaReiser
commented
6 months ago Could you share some more details. What platform and os are you using? Were you able to successfully build older versions from source ?
wuch-g2v
commented
6 months ago What platform and os are you using?
Above does not work on Linux x86/64 and aarch64, and OpenSolaris x86/64 in all cases using gcc 14. Included build log is from our distro build automation on Linux x86/64. That distro is relatively close to Fedora rawhide so it should be possible to reproduce this issue on top of it.
Were you able to successfully build older versions from source ?
Prev version with which my colleague been trying to use LTO was 0.3.8 and such build failed as well however he had no time to report that so I'm doing that now. As you may see on included build log all LTO settings are injected over env variables (which generally works in case all cargo using projects).
charliermarsh
commented
6 months ago We don't really control any of this AFAICT, perhaps something that should be filed in Maturin? \cc @messense if this one is obvious to you.
messense
commented
6 months ago Can you reproduce it with cargo build? These is no special handling of LTO in maturin. Probably a Rust/Cargo issue or dependency issue given that solaris is a tier 2 w/o host tools in Rust platform support.
messense
commented
6 months ago BTW, if you want to change linker, you should probably use CARGO_TARGET_<triple>_LINKER env var.
konstin
commented
6 months ago I can perform a release build with lto = "fat" on x64_64 ubuntu 24.04 (gcc 13.2.0) and a fedora:rawhide docker container. Can you provide instructions to reproduce your failure?
wuch-g2v
commented
6 months ago I can perform a release build with
lto = "fat"on x64_64 ubuntu 24.04 (gcc 13.2.0) and afedora:rawhidedocker container. Can you provide instructions to reproduce your failure?
All lines wot "+ " on begging are commands logged in this build log.
wuch-g2v
commented
6 months ago BTW, if you want to change linker, you should probably use
CARGO_TARGET_<triple>_LINKERenv var.
If that is true .. why cargo/rust do not honor standard env variables contents? 🤔 In this case it should be used $LD (I'v tested that and it is not used)
eli-schwartz
commented
6 months ago The problem here is one which is well known to Gentoo Linux. Rust uses LLVM for code generation, and LTO of rust code works fine. Inside ruff's dependency tree is the jemalloc crate, which in turn builds a private copy of jemalloc using GCC with -flto.
You cannot combine LTO bytecode from GCC together with LLVM and get meaningful results.
Gentoo suppresses LTO for CC / CXX when building cargo packages:
https://bugs.gentoo.org/893658 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc51935f7aae5f89d1ffecabef322680979952b8
eli-schwartz
commented
6 months ago A better solution may be telling the jemalloc-sys crate to use the system jemalloc library...
Looks like
ruffis not LTO ready.