Created attachment 859297 [details] build.log On my clang/musl/23.0 test machine I've run across a LFS change causing an issue with compiling rust. This is known upstream but highlighting here as it effects the 23.0 profiles. Reproduce: 1. Setup llvm/musl with a 23.0 profile 2. emerge -va sys-libs/musl-9999 3. emerge -va dev-lang/rust Error: ld.lld: error: undefined symbol: stat64
https://github.com/rust-lang/rust/pull/107129 was finally merged which should unblock https://github.com/rust-lang/libc/pull/3068 which should unblock https://github.com/rust-lang/libc/pull/2935.
As of dev-lang/rust-1.69.0-r1 this seems like it compiling on a musl-1.2.4 system.
I'm still running into this issue.
tinderbox_musl has reproduced this issue with version 1.69.0-r1 - Updating summary.
Taking back earlier comment of it working as it was a one time thing I can't get to work again.
I've put together a quite bad hack to fix this that applies the two unmerged PRs to all three versions of the libc crate bundled with rust. Unfortunately since the compilation errors are caused by the already-compiled std crate from the bootstrapping rust version, this patch requires you to to first downgrade to musl 1.2.3, then compile rust, then upgrade back to musl 1.2.4, and then do any further rust updates with system-bootstrap. Any suggestions on how to make this not a bad hack would be appreciated. patch: https://0x0.st/HN4m.4.patch
Fixed. https://github.com/gentoo/gentoo/commit/515b5920046117355d88b3494c74da269ce9b30a
(In reply to orbea from comment #7) > Fixed. > > https://github.com/gentoo/gentoo/commit/ > 515b5920046117355d88b3494c74da269ce9b30a Is it possible to skip that patch, and continue with the soon to be released rust-1.73.0 instead?
> Is it possible to skip that patch, and continue with the soon to be released rust-1.73.0 instead? It was already merged in ::gentoo and its not my call, but is there a reason why?
well, I read in one the many pullrequests, or one of the bugs concerning the whole rust breaking due to lfs changes in musl-1.2.4 that it is a rather complicated process, requesting multiple patching and rebootstraps. musl is not considered a blocker while stabilizing, so it's possible it will break at some point, therefore it *might* be a better idea to wait for a fixed rust-stage, and to continue with a fully fixed dev-lang/rust. if you're aware of all the precautions to take, a musl specific news item would be great!?
(In reply to tt_1 from comment #10) > well, I read in one the many pullrequests, or one of the bugs concerning the > whole rust breaking due to lfs changes in musl-1.2.4 that it is a rather > complicated process, requesting multiple patching and rebootstraps. > > musl is not considered a blocker while stabilizing, so it's possible it will > break at some point, therefore it *might* be a better idea to wait for a > fixed rust-stage, and to continue with a fully fixed dev-lang/rust. > > if you're aware of all the precautions to take, a musl specific news item > would be great!? This just sounds based on speculation? I'm not aware of any real issues with vimproved's approach. It's using a newer version for bootstrapping. I think you're referring to an older approach that was considered but not merged.
