Open he32 opened 10 months ago
he32
commented
10 months ago This doesn't appear to be a resource shortage issue, the virtual size of rustc at the time of ICE was around 230MB, and doing "unlimit datasize" before building makes no difference.
saethlin
commented
10 months ago Yikes I just tried using Miri to replicate such a cross-build, and got these compile errors from
cargo +nightly miri test --target=mipsel-unknown-netbsderror[E0308]: mismatched types
--> /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/thread.rs:387:59
|
387 | ... match libc::_cpuset_isset(i, set) {
| ------------------- ^ expected `u32`, found `u64`
| |
| arguments to this function are incorrect
|
note: function defined here
--> /home/ben/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libc-0.2.150/src/unix/bsd/netbsdlike/netbsd/mod.rs:2782:12
|
2782 | pub fn _cpuset_isset(cpu: cpuid_t, set: *const cpuset_t) -> ::c_int;
| ^^^^^^^^^^^^^
help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit
|
387 | match libc::_cpuset_isset(i.try_into().unwrap(), set) {
| ++++++++++++++++++++
error[E0277]: the trait bound `i32: core::convert::From<u32>` is not satisfied
--> /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/thread_parking/netbsd.rs:37:37
|
37 | tv_nsec: dur.subsec_nanos().into(),
| ^^^^ the trait `core::convert::From<u32>` is not implemented for `i32`
|
= help: the following other types implement trait `core::convert::From<T>`:
<i32 as core::convert::From<bool>>
<i32 as core::convert::From<i8>>
<i32 as core::convert::From<i16>>
<i32 as core::convert::From<u8>>
<i32 as core::convert::From<u16>>
<i32 as core::convert::From<core::num::NonZeroI32>>
= note: required for `u32` to implement `core::convert::Into<i32>`Have you patched std to fix this?
he32
commented
10 months ago Yes, we found that cpuid_t was mis-defined on NetBSD, causing issues for all our ILP32 targets.
Let's see... That's https://github.com/rust-lang/rust/pull/116665.
I have re-tried with binaries of rust 1.73.1 (fails the same way as 1.74.1) and 1.72.1, which comes across this hurdle. The slow build on my qemu-hosted mips32-based "mipsel" host has now come to
===> Building for cbindgen-0.26.0
Compiling proc-macro2 v1.0.66
Compiling quote v1.0.27
Compiling unicode-ident v1.0.8
Compiling libc v0.2.144and is still going.
I have a suspicion that this is an LLVM issue -- all these rust variants were (cross-)built with the LLVM which comes embedded in the rust compiler source tar file. And I have a further vague suspicion that this is a CPU-family issue and not a OS/platform issue, so re-trying this with one of the Linux mipsel targets should (if my suspcion is correct) reproduce the issue.
saethlin
commented
10 months ago It would not at all surprise me if this is just another MIPS miscompilation.
he32
commented
10 months ago Just for reference:
rust 1.72.1 contains LLVM version 16.0.5
rust 1.73.0 contains LLVM version 17.0.2
rust 1.74.1 contains LLVM version 17.0.4However, building rust 1.74.1 natively with an external LLVM (which might make 1.74.1 succeed) presents its own set of challenges, due to this platform's inability to handle sufficient physical memory to make such a build feasible within finite time. I've maxed out the VM with 512MB "physical" memory, and that will just be inadequate to host a native build of rust. The only hope (which I've not yet set up), is to use a 32-bit chroot inside a 64-bit mips64 system (which can handle more physical memory).
Code
Actually, "try to build cbindgen" is the test case.
Meta
rustc --version --verbose:Error output
Backtrace
See above. I think that's already included...