Closed bugadani closed 2 years ago
I haven't tried bisecting it, I can only confirm that the same project compiles fine with nightly-2022-04-01
I have had the same issue. Idk how to solve it though. :(
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
Will be fixed once this is merged: https://github.com/rust-lang/rust/pull/94609
Thanks, this has been fixed now.
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