1.30.0 fails to build for target powerpc-unknown-netbsd

[he32]

I've cross-built and built natively rust 1.29.2 for (among others) powerpc-unknown-netbsd, and this appears to work fine. I'm now trying to upgrade to rust 1.30.0, and have managed to build it natively (on amd64 / x86_64) and cross-built for sparc64. However, the cross-build for the powerpc target fails with rust type mismatch compile errors, such as this:

   Compiling openssl v0.10.11
...
error[E0308]: mismatched types
  --> vendor/openssl/src/nid.rs:87:62
   |
87 |                 .map(|nameptr| str::from_utf8(CStr::from_ptr(nameptr).to_bytes()).unwrap())
   |                                                              ^^^^^^^ expected u8, found i8
   |
   = note: expected type `*const u8`
              found type `*mut i8`

error[E0308]: mismatched types
  --> vendor/openssl/src/nid.rs:98:62
   |
98 |                 .map(|nameptr| str::from_utf8(CStr::from_ptr(nameptr).to_bytes()).unwrap())
   |                                                              ^^^^^^^ expected u8, found i8
   |
   = note: expected type `*const u8`
              found type `*mut i8`

Another example is:

error[E0308]: mismatched types
  --> vendor/openssl/src/version.rs:63:24
   |
63 |         CStr::from_ptr(OpenSSL_version(OPENSSL_VERSION))
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected u8, found i8

Now, what separates the NetBSD/powerpc target from amd64 and sparc64 is that on NetBSD/powerpc, the char type is unsigned char, whereas on the other two, it is signed char.

Has rust between 1.29.2 and 1.30.0 introduced code which makes assumptions about the signedness of the C type "char"? I've tried diff'ing the various openssl dirs between the two versions, but have unfortunately not found the problem.

[he32]

Oh, btw, the cross-build of rust 1.30.0 from NetBSD/amd64 to NetBSD/earmv7hf fails the same way, and NetBSD/earmv7hf also has char == unsigned char.

[he32]

https://pastebin.com/UXUeEHdJ contains a more complete build error log, for 1 month forward.

[pnkfelix]

T-compiler triage. Tagged this stable-to-stable regression with T-compiler.

It needs a P-priority tag. I don't think powerpc-*-netbsd is a Tier 1 platform ... I don't know whether that means this should be considered P-medium ... it would probably be a good idea to at least double-check what happened here.

(It seems like it should in theory be relatively easy to make a standalone test for this and then bisect to what nightly injected it...)

[he32]

Note that this problem also appears when (cross-)building for NetBSD/earmv7hf.
That platform also has char == u_char. And I believe we would also see this when
building for NetBSD/aarch64; it has the same feature that char is unsigned.

[he32]

I've been looking around, and have found the file src/vendor/libc/src/unix/bsd/netbsdlike/netbsd/mod.rs, which unconditionally defines c_char to i8. This file comes directly from the tar.gz file for rustc 1.30.1. However, I've not been able to find an entry on github for this exact file. I have however found src/liblibc/src/unix/bsd/netbsdlike/netbsd/mod.rs which is on github, and which is quite a bit newer than the src/vendor/ file; among the "missing" fixes is the commit which fixed the signedness of c_char on NetBSD for powerpc and arm, but apparently also other missing commits.

The question is therefore now: where does src/vendor/libc/src/unix/bsd/netbsdlike/netbsd/mod.rs come from, and why has it fallen so far behind the (presumed) original at src/liblibc/src/unix/bsd/netbsdlike/netbsd/mod.rs?

[memoryruins]

The commit for fixing the signedness is in rust-lang/libc#1057

vendor is also in the nightly tar.gz, except the folder is now at top-level rather than inside src.
It is still out of date in that vendor/libc.

edit: I assume it’s to provide a local copy of any crates.io deps when it’s shipped. Something may be still using an outdated libc. Forwarding to others who would know what stage the vendor folder is included.

edit 2: When the source tarball is produced, a builder on CI populates the vendor directory using cargo vendor

[he32]

The commit for fixing the signedness is in rust-lang/libc#1057

Yep, I know. It's a bit frustrating having to re-discover old and already-solved bugs.

I'm trying to copy over the contents from the "new" directory to the vendor/libc/ tree, and doctoring the src/vendor/libc/.cargo-checksum.json file by modifying the mod.rs checksum and adding the checksum for all the "new" files, but the build (cargo?) still insists on doing downloads in the build phase (and failing...), which it didn't before I messed with this. Is this because the "package" checksum is now wrong, and how is it (re)computed?

[memoryruins]

Is this because the "package" checksum is now wrong, and how is it (re)computed?

cc @alexcrichton

After grepping the source tarball for libc deps,

src/bootstrap/Cargo.toml
43:libc = "0.2"

src/librustc_codegen_ssa/Cargo.toml
19:libc = "0.2.43"

vendor/wait-timeout/Cargo.toml
21:libc = "0.2"

vendor/termion/Cargo.toml
13:libc = "0.2.8"

vendor/commoncrypto-sys/Cargo.toml
15:libc = "0.2"

src/tools/compiletest/Cargo.toml
20:libc = "0.2"

src/tools/cargo/Cargo.toml
41:libc = "0.2"

src/stdsimd/crates/stdsimd/Cargo.toml
23:libc = "0.2"

librustc_codegen_ssa is using an outdated libc.

src/librustc_codegen_ssa/Cargo.toml
19:libc = "0.2.43"

libc 0.2.43 was released hours before the patch for arm and powerpc was merged.

0.2.44 is now on crates.io

It would be better if librustc_codegen_ssa and the other deps in Cargo.lock were updated rather than you needing to doctor the files, especially if it's all that's needed.

@eddyb @bjorn3 could this version bump be included in the refactoring occurring in #56198? Could it be set to 0.2 like the rest of the crates in rustc?

edit: if the refactor might take awhile, then a version bump could be its own PR (and backported?)

[eddyb]

edit: if the refactor might take awhile, then a version bump could be its own PR (and backported?)

Yeah that's better.