Upgrading to cc@1.0.84 breaks libstd bootstrap

[wesleywiser]

Right now, rust-lang/rust uses cc@1.79. If I attempt to upgrade to cc@1.84, I get a bunch of errors from bootstrap.

Building stage0 library artifacts (x86_64-unknown-linux-gnu)
  Downloaded cc v1.0.84
  Downloaded 1 crate (74.9 KB) in 0.53s
   Compiling libc v0.2.150
   Compiling core v0.0.0 (/home/wesley/rust/library/core)
   Compiling memchr v2.5.0
   Compiling std v0.0.0 (/home/wesley/rust/library/std)
error: unexpected `cfg` condition name
  --> library/core/src/num/mod.rs:29:11
   |
29 | #[cfg(not(no_fp_fmt_parse))]
   |           ^^^^^^^^^^^^^^^
   |
   = note: `-D unexpected-cfgs` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(unexpected_cfgs)]`

error: unexpected `cfg` condition name
  --> library/core/src/num/mod.rs:31:11
   |
31 | #[cfg(not(no_fp_fmt_parse))]
   |           ^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
  --> library/core/src/num/mod.rs:33:11
   |
33 | #[cfg(not(no_fp_fmt_parse))]
   |           ^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
  --> library/core/src/num/mod.rs:35:11
   |
35 | #[cfg(not(no_fp_fmt_parse))]
   |           ^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
  --> library/core/src/num/mod.rs:56:11
   |
56 | #[cfg(not(no_fp_fmt_parse))]
   |           ^^^^^^^^^^^^^^^

error: unexpected `cfg` condition value
   --> library/core/src/mem/mod.rs:733:19
    |
733 |     #[cfg(not(any(target_arch = "spirv")))]
    |                   ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_arch` are: `aarch64`, `arm`, `avr`, `bpf`, `csky`, `hexagon`, `loongarch64`, `m68k`, `mips`, `mips32r6`, `mips64`, `mips64r6`, `msp430`, `nvptx64`, `powerpc`, `powerpc64`, `riscv32`, `riscv64`, `s390x`, `sparc`, `sparc64`, `wasm32`, `wasm64`, `x86`, `x86_64`

error: unexpected `cfg` condition value
   --> library/core/src/ffi/mod.rs:244:5
    |
244 |     target_arch = "asmjs",
    |     ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_arch` are: `aarch64`, `arm`, `avr`, `bpf`, `csky`, `hexagon`, `loongarch64`, `m68k`, `mips`, `mips32r6`, `mips64`, `mips64r6`, `msp430`, `nvptx64`, `powerpc`, `powerpc64`, `riscv32`, `riscv64`, `s390x`, `sparc`, `sparc64`, `wasm32`, `wasm64`, `x86`, `x86_64`

error: unexpected `cfg` condition value
   --> library/core/src/ffi/mod.rs:273:5
    |
273 |     target_arch = "asmjs",
    |     ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_arch` are: `aarch64`, `arm`, `avr`, `bpf`, `csky`, `hexagon`, `loongarch64`, `m68k`, `mips`, `mips32r6`, `mips64`, `mips64r6`, `msp430`, `nvptx64`, `powerpc`, `powerpc64`, `riscv32`, `riscv64`, `s390x`, `sparc`, `sparc64`, `wasm32`, `wasm64`, `x86`, `x86_64`

error: unexpected `cfg` condition value
   --> library/core/src/ffi/mod.rs:434:5
    |
434 |     target_arch = "asmjs",
    |     ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_arch` are: `aarch64`, `arm`, `avr`, `bpf`, `csky`, `hexagon`, `loongarch64`, `m68k`, `mips`, `mips32r6`, `mips64`, `mips64r6`, `msp430`, `nvptx64`, `powerpc`, `powerpc64`, `riscv32`, `riscv64`, `s390x`, `sparc`, `sparc64`, `wasm32`, `wasm64`, `x86`, `x86_64`

error: unexpected `cfg` condition value
   --> library/core/src/ffi/mod.rs:464:9
    |
464 |     not(target_arch = "asmjs"),
    |         ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_arch` are: `aarch64`, `arm`, `avr`, `bpf`, `csky`, `hexagon`, `loongarch64`, `m68k`, `mips`, `mips32r6`, `mips64`, `mips64r6`, `msp430`, `nvptx64`, `powerpc`, `powerpc64`, `riscv32`, `riscv64`, `s390x`, `sparc`, `sparc64`, `wasm32`, `wasm64`, `x86`, `x86_64`

error: unexpected `cfg` condition value
   --> library/core/src/ffi/mod.rs:398:9
    |
398 |         target_arch = "asmjs",
    |         ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_arch` are: `aarch64`, `arm`, `avr`, `bpf`, `csky`, `hexagon`, `loongarch64`, `m68k`, `mips`, `mips32r6`, `mips64`, `mips64r6`, `msp430`, `nvptx64`, `powerpc`, `powerpc64`, `riscv32`, `riscv64`, `s390x`, `sparc`, `sparc64`, `wasm32`, `wasm64`, `x86`, `x86_64`

error: unexpected `cfg` condition value
   --> library/core/src/ffi/mod.rs:416:13
    |
416 |         not(target_arch = "asmjs"),
    |             ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_arch` are: `aarch64`, `arm`, `avr`, `bpf`, `csky`, `hexagon`, `loongarch64`, `m68k`, `mips`, `mips32r6`, `mips64`, `mips64r6`, `msp430`, `nvptx64`, `powerpc`, `powerpc64`, `riscv32`, `riscv64`, `s390x`, `sparc`, `sparc64`, `wasm32`, `wasm64`, `x86`, `x86_64`

error: unexpected `cfg` condition name
  --> library/core/src/fmt/mod.rs:16:11
   |
16 | #[cfg(not(no_fp_fmt_parse))]
   |           ^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
  --> library/core/src/fmt/mod.rs:18:7
   |
18 | #[cfg(no_fp_fmt_parse)]
   |       ^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
   --> library/core/src/../../stdarch/crates/core_arch/src/x86/mod.rs:782:11
    |
782 | #[cfg(not(stdarch_intel_sde))]
    |           ^^^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
   --> library/core/src/../../stdarch/crates/core_arch/src/x86/mod.rs:784:11
    |
784 | #[cfg(not(stdarch_intel_sde))]
    |           ^^^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
   --> library/core/src/../../stdarch/crates/core_arch/src/x86/mod.rs:787:11
    |
787 | #[cfg(not(stdarch_intel_sde))]
    |           ^^^^^^^^^^^^^^^^^

error: unexpected `cfg` condition name
   --> library/core/src/../../stdarch/crates/core_arch/src/x86/mod.rs:789:11
    |
789 | #[cfg(not(stdarch_intel_sde))]
    |           ^^^^^^^^^^^^^^^^^

error: could not compile `core` (lib) due to 18 previous errors

I believe the issue is the dependency on libc

cc-rs/Cargo.toml

Line 24 in 802399f

libc = { version = "0.2.62", default-features = false }

which does not activate the rustc-dep-of-std feature in this case.

[thomcc]

I guess we'd take a patch that avoids a libc dep by manually writing extern blocks.

[NobodyXu]

jobserver also uses libc, so I wonder why it can compile back then.

Maybe we can add a new feature rustc-dep-of-std?

[ChrisDenton]

Iirc jobserver used to be optional.

[NobodyXu]

Iirc jobserver used to be optional.

Thanks, so rustc didn't enable cc/parallel.

Does adding a new feature rustc-dep-of-std makes sense?

[ChrisDenton]

That's usually used to enable a special workspace hack, which shouldn't be needed here as cc isn't a true dependency of std. I assume it's just a dev dependency due to a build script.

But if adding a feature helps avoid this issue then I guess it makes the most sense.

[NobodyXu]

libc is used in job_token and os_pipe:

./job_token/unix.rs:                Some(libc::O_RDONLY) | Some(libc::O_RDWR),
./job_token/unix.rs:                Some(libc::O_WRONLY) | Some(libc::O_RDWR),
./job_token/unix.rs:        let mut fds = [libc::pollfd {
./job_token/unix.rs:            events: libc::POLLIN,
./job_token/unix.rs:        let ret = cvt(unsafe { libc::poll(fds.as_mut_ptr(), 1, 0) })?;
./job_token/unix.rs:    let ret = unsafe { libc::fcntl(file.as_raw_fd(), libc::F_SETFL, libc::O_NONBLOCK) };
./job_token/unix.rs:    let ret = unsafe { libc::fcntl(file.as_raw_fd(), libc::F_GETFL) };
./job_token/unix.rs:    Some(ret & libc::O_ACCMODE)
./os_pipe/unix.rs:            cvt(libc::pipe2(fds.as_mut_ptr(), libc::O_CLOEXEC))?;
./os_pipe/unix.rs:            cvt(libc::pipe(fds.as_mut_ptr()))?;
./os_pipe/unix.rs:            cvt(libc::ioctl(fd, libc::FIOCLEX))?;
./os_pipe/unix.rs:            let previous = cvt(libc::fcntl(fd, libc::F_GETFD))?;
./os_pipe/unix.rs:            let new = previous | libc::FD_CLOEXEC;
./os_pipe/unix.rs:                cvt(libc::fcntl(fd, libc::F_SETFD, new))?;

It uses function fcntl(fd, F_GETFD | F_SETFD), ioctl(fd, libc::FIOCLEX), libc::pipe, libc::pipe2andlibc::poll`, plus a lot of constants.

I actually want to get rid of the libc dependency to speedup cc compilation, but I'm a bit worried about defining the type alias (nfds_t from libc::poll) and other constants in a cross-platform manner.

If we can get it right though, I would definitely be in favor of removing libc.

[roblabla]

There are other issues with upgrading cc in libstd, see this issue

[thomcc]

That's usually used to enable a special workspace hack, which shouldn't be needed here as cc isn't a true dependency of std. I assume it's just a dev dependency due to a build script.

IIRC this is because rustc's workspace is still on the old resolver, which is hard to fix (or so I've been told).

Anyway, I'll see if I can get to this next weekend or so.

[dpaoliello]

That's usually used to enable a special workspace hack, which shouldn't be needed here as cc isn't a true dependency of std. I assume it's just a dev dependency due to a build script.

IIRC this is because rustc's workspace is still on the old resolver, which is hard to fix (or so I've been told).

Anyway, I'll see if I can get to this next weekend or so.

Any luck with this?

[mqudsi]

I actually want to get rid of the libc dependency to speedup cc compilation, but I'm a bit worried about defining the type alias (nfds_t from libc::poll) and other constants in a cross-platform manner.

I have a crate that I wrote for fish that might help make this less error-prone, but the catch is that it depends on cc-rs in turn. If it's a build dependency I think cargo should still be able to resolve it?

It's a very basic version of autoconf for rust, allowing checking system provided types and testing C preprocessor predicates. For constant values and expressions (sizeof, #define values, etc) you can get their values as build-time constants (there are some compatible with cross compilation and others that only work for native, but they're all annotated as such).

[NobodyXu]

Thanks, but with #985 we would add back jobserver dependency (and jobserver depends on libc), so I don't think we can remove libc as a dependency anymore.

[dpaoliello]

cc-rs has been updated in rust-lang/rust, so I believe that this issue can be marked as completed.