rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
97.2k stars 12.56k forks source link

`std` no longer compiles for `riscv32imc-esp-espidf` #95924

Closed bugadani closed 2 years ago

bugadani commented 2 years ago

I'm trying to cross-copmile for an espidf target from Windows, but in the latest nightly compilation (or in this case, cargo c) fails with the following errors:

cargo c --target=riscv32imc-esp-espidf -Z build-std=std,panic_abort

error[E0308]: mismatched types
   --> C:\Users\bugad\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\os\unix\process.rs:166:33
    |
166 |         self.as_inner_mut().uid(id);
    |                                 ^^ expected `u16`, found `u32`
    |
help: you can convert a `u32` to a `u16` and panic if the converted value doesn't fit
    |
166 |         self.as_inner_mut().uid(id.try_into().unwrap());
    |                                   ++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\bugad\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\os\unix\process.rs:175:33
    |
175 |         self.as_inner_mut().gid(id);
    |                                 ^^ expected `u16`, found `u32`
    |
help: you can convert a `u32` to a `u16` and panic if the converted value doesn't fit
    |
175 |         self.as_inner_mut().gid(id.try_into().unwrap());
    |                                   ++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\bugad\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\os\unix\process.rs:184:36
    |
184 |         self.as_inner_mut().groups(groups);
    |                                    ^^^^^^ expected `u16`, found `u32`
    |
    = note: expected reference `&[u16]`
               found reference `&[u32]`

error[E0308]: mismatched types
   --> C:\Users\bugad\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\unix\fd.rs:112:17
    |
112 |                 offset as i64,
    |                 ^^^^^^^^^^^^^ expected `i32`, found `i64`
    |
help: you can convert an `i64` to an `i32` and panic if the converted value doesn't fit
    |
112 |                 (offset as i64).try_into().unwrap(),
    |                 +             +++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\bugad\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\unix\fd.rs:179:17
    |
179 |                 offset as i64,
    |                 ^^^^^^^^^^^^^ expected `i32`, found `i64`
    |
help: you can convert an `i64` to an `i32` and panic if the converted value doesn't fit
    |
179 |                 (offset as i64).try_into().unwrap(),
    |                 +             +++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\bugad\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\unix\fs.rs:969:56
    |
969 |         let n = cvt(unsafe { lseek64(self.as_raw_fd(), pos, whence) })?;
    |                                                        ^^^ expected `i32`, found `i64`
    |
help: you can convert an `i64` to an `i32` and panic if the converted value doesn't fit
    |
969 |         let n = cvt(unsafe { lseek64(self.as_raw_fd(), pos.try_into().unwrap(), whence) })?;
    |                                                           ++++++++++++++++++++
bugadani commented 2 years ago

I haven't tried bisecting it, I can only confirm that the same project compiles fine with nightly-2022-04-01

RangerDevv commented 2 years ago

I have had the same issue. Idk how to solve it though. :(

gyscos commented 2 years ago

Looking at the first error: a uid() function is called with a u32, but it expected a u16.

The function is called here: https://github.com/rust-lang/rust/blob/master/library/std/src/os/unix/process.rs#L166 Here the argument (we know it's a u32 from the error message) depends on the target_os; it's u16 for vxworks, and u32 for everything else.

The function is defined here: https://github.com/rust-lang/rust/blob/master/library/std/src/sys/unix/process/process_common.rs#L199 The argument type is libc::uid_t.

That type is defined here: https://github.com/rust-lang/libc/blob/f0f4b689906862bf74297042022c20ada7274b71/src/unix/mod.rs#L33 It's a c_ushort (u16) on the espidf target OS.

So at least we understand the issue. Now - why was it working before? Did any of these definitions change recently? None of the files linked here have recent relevant commits that could have changed that. Maybe the libc version was updated recently? Libc updated the uid_t definition on March 12nd: https://github.com/rust-lang/libc/commit/ab62380241b431beb929a2f986fe08375e87a091#diff-a828924ffbc30c564e49bc3652ffa5375a123671b228fc99b5775a29cff6eea5R27 from the PR https://github.com/rust-lang/libc/pull/2708

A fix could be to use libc::uid_t as parameter type in CommandExt::uid, rather than u32 for all non-vxworks platform? Or if we don't want to expose libc here, re-export just its uid_t type, or re-implement the type definition?

The same thing happened with libc::gid_t.

Then, probably the same with off_t from libc, which was i64 before and is now c_long on espidf (which is i32)

Ah looks like the fix is in the works: https://github.com/rust-lang/rust/pull/94609

ivmarkov commented 2 years ago

Will be fixed once this is merged: https://github.com/rust-lang/rust/pull/94609

bugadani commented 2 years ago

Thanks, this has been fixed now.