I see that there's been a fix committed, to have rust not use the value of $CC for its linker. Thanks Sam!
https://github.com/gentoo/gentoo/commit/f65ef3fddd9ef9cc3d2d172f6da9a39231b1e2d1#diff-dbba975de76b74289aaec5ad12154eaf03e0ce9a8cfd09ff73b8a0d5536a3a9b On my system it now calls aarch64-unknown-linux-gnu-cc as its linker, which gives us GNU ld instead of llvm's. Was this intentional and is it supported? I'm not that familiar with rustc. It does seem a little odd to use GNU ld on an llvm profile, but maybe it's fine. For the record, the setting of CC=clang-19 wasn't my own doing. It seems that this happens with USE=system-llvm. In this case, the rust ebuild calls `llvm-r1_pkg_setup`, which calls `llvm_fix_clang_version CC CPP CXX`, which rewrites those environment variables to use the version-numbered clang binary. https://github.com/gentoo/gentoo/blob/f65ef3fddd9ef9cc3d2d172f6da9a39231b1e2d1/dev-lang/rust/rust-1.85.1.ebuild#L287 https://github.com/gentoo/gentoo/blob/f65ef3fddd9ef9cc3d2d172f6da9a39231b1e2d1/eclass/llvm-r1.eclass#L238 https://github.com/gentoo/gentoo/blob/f65ef3fddd9ef9cc3d2d172f6da9a39231b1e2d1/eclass/llvm-utils.eclass#L63 Thanks again, everyone. > On Mar 20, 2025, at 11:04, Nate Eldredge <n...@thatsmathematics.com> wrote: > > > >> On Mar 20, 2025, at 10:45, Eli Schwartz <eschwa...@gentoo.org> wrote: >> >> On 3/20/25 11:54 AM, Nate Eldredge wrote: >>> On Mar 20, 2025, at 00:07 Eli Schwartz <eschwa...@gentoo.org> wrote: >>>> You can also pass -C linker=clang if you like. Portage will >>>> already do this for rust software packaged in ::gentoo. >>> >>> Well, not across the board, it seems, because I became aware of the >>> issue when dev-util/maturin failed to emerge. In the build.log >>> (attached) we can see that some of the rustc commands use -C >>> linker=clang but others do not, and they fail. Is that a separate >>> bug? >> >> >> Your build.log confuses me. >> >> >> Same `cargo build` run, but -C linker is not being passed to proc >> macros? or? > > They might not be the same run; I have MAKEOPTS="-j6 -l6.2" so it could be > two separate `cargo build` in parallel. Sorry for the confusion. Here's a > simpler build.log with MAKEOPTS="". Here proc-macro2 is built first, and it > fails. >
build2.log
Description: Binary data
> > Thanks again for looking at this.
