Summary: | =dev-lang/rust-1.73.0 fail to work after successfully compile, with Arm64 Musl LLVM Stage3 rootfs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | labyrithfind <jacksonhub2> |
Component: | Current packages | Assignee: | Gentoo Rust Project <rust> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | jacksonhub2, navi, randy, rust |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
labyrithfind
2023-11-17 12:06:18 UTC
Please keep in mind that the musl/llvm stage3s are experimental still. I'm not sure why you have anything in .cargo or how it relates to dev-lang/rust or dev-lang/rust-bin though. Hi @Sam, thanks for your remarks. Yes the reason i post on this, is that i found the Rust Stage0 compiler during the compile of dev-lang/rust, is also facing the same issue. Stage0 binaries, is the same rust executable, that you installed in .cargo folder, and it's producing errors. Despite the rust package is compiled, its main binary file such like rustc, is not able to use as expected. Would much appreciated if you can share us some ideas on this, thansk! (Let's not confuse matters with upstream's rustup binary - that's expected not to work, for the same reason that dev-lang/rust-bin (and dev-lang/rust) need hacks for bootstrap binaries.) I think for dev-lang/rust-bin in the past, we considered some hacks to work around the Unwind_* symbol problems -- it requires libgcc's unwind. I've got to be honest though, this was about 2 years ago that I last looked into it, so the details are fuzzy for me at the moment. From a quick grep, it looks like only dev-lang/rust has the needed workarounds right now. Not clear to me why dev-lang/rust would fail - it's possible we haven't wired up the aforementioned hacks for arm64, just amd64 (see esetup_unwind_hack in dev-lang/rust's ebuild). Hi @Sam, Thanks for your help, i would have this do some test to see how it goes. Appreciated. |