Newer libc versions (0.2.113 or later) don't compile with Rust-GPU's rust-toolchain.

[Makogan]

Expected Behaviour

Following the steps described in the docs should work without errors in the supported platforms.

Example & Steps To Reproduce

1. Create a new blanket rust project with cargo new
2. Copy the rust tool-chain file from git onto the root of the project
3. Add [build-dependencies] spirv-builder = { git = "https://github.com/EmbarkStudios/rust-gpu" } to the toml file.
4. Create a build.rs file, copy the snippet from the docs and replace the path to the shader and the target with the relevant strings.

System Info

• Rust: rust version rustc 1.62.0-nightly (1f7fb6413 2022-04-10)
• OS: Ubuntu 22.04
• GPU: Nvidia GTX 1070
• SPIR-V: vulkan

Backtrace

error[E0658]: `const extern fn` definitions are unstable
    --> /home/makogan/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/libc-0.2.131/src/macros.rs:188:17
     |
188  | /                 pub $($constness)* unsafe extern fn $i($($arg: $argty),*
189  | |                 ) -> $ret {
190  | |                     $($body);*
191  | |                 }
     | |_________________^
     |
    ::: /home/makogan/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/libc-0.2.131/src/unix/linux_like/mod.rs:1499:1
     |
1499 | / f! {
1500 | |     pub fn CMSG_FIRSTHDR(mhdr: *const msghdr) -> *mut cmsghdr {
1501 | |         if (*mhdr).msg_controllen as usize >= ::mem::size_of::<cmsghdr>() {
1502 | |             (*mhdr).msg_control as *mut cmsghdr
...    |
1545 | |     }
1546 | | }
     | |_- in this macro invocation
     |
     = note: see issue #64926 <https://github.com/rust-lang/rust/issues/64926> for more information
     = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable
     = note: this error originates in the macro `f` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: `const extern fn` definitions are unstable
    --> /home/makogan/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/libc-0.2.131/src/macros.rs:203:17
     |
203  | /                 pub $($constness)* extern fn $i($($arg: $argty),*
204  | |                 ) -> $ret {
205  | |                     $($body);*
206  | |                 }
     | |_________________^
     |
    ::: /home/makogan/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/libc-0.2.131/src/unix/linux_like/mod.rs:1548:1
     |
1548 | / safe_f! {
1549 | |     pub fn SIGRTMAX() -> ::c_int {
1550 | |         unsafe { __libc_current_sigrtmax() }
1551 | |     }
...    |
1615 | |     }
1616 | | }
     | |_- in this macro invocation
     |
     = note: see issue #64926 <https://github.com/rust-lang/rust/issues/64926> for more information
     = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable
     = note: this error originates in the macro `safe_f` (in Nightly builds, run with -Z macro-backtrace for more info)

[RustyBamboo]

Had the same issue. Looks like some of the deep dependencies are assuming newer nightly Rust versions.

Quick fix:
replace your Cargo.lock with rust-gpu's Cargo.lock

[watjurk]

Here is another quick fix, that does not require to replace the whole Cargo.lock file:

[dependencies]
spirv-builder = { git="https://github.com/EmbarkStudios/rust-gpu" }
libc = "=0.2.112" # Add this to your Cargo.toml. This version number is extracted from rust-gpu's Cargo.lock

I think this issue boils down to spirv-builder not specifying libc version that is compatible with toolchain specified in rust-gpu's rust-toolchain file. The examples from rust-gpu are working because the Cargo.lock file specifies version of libc that is used in rust-gpu's codebase and this specific version of libc IS compatible with toolchain mentioned above.

The general fix would be to introduce specific libc version in spirv-builder's Cargo.toml file.

[oisyn]

I've just followed the exact steps from the docs and I can't really repro your issue. I've also tried a lot of the older libc releases, as there have been quite some releases in the past 2 weeks, but everything went fine on my end. This even includes the yanked versions: 0.2.128 and 0.2.130. So I'm not really sure where this problem comes from.

Do you know which libc version you were on?

Also a sidenote: I've published all public-facing rust-gpu crates and their dependencies to crates.io last week. So instead of referencing from the github, you can now fetch them from crates.io directly. Latest version is 0.4.0-alpha.14. I still need to update the docs.

I've put my test setup on github: https://github.com/oisyn/rust-gpu-empty (which references the published crates, but if you go back one commit you'll get the github references)

[watjurk]

The non-working libc version for me is v0.2.131, also I'm using nightly-2022-04-11-aarch64-apple-darwin toolchain.

rustup show:

Default host: aarch64-apple-darwin
rustup home:  /Users/wiktorjurkiewicz/.rustup

installed toolchains
--------------------

stable-aarch64-apple-darwin
nightly-2022-04-11-aarch64-apple-darwin
nightly-aarch64-apple-darwin (default)

active toolchain
----------------

nightly-2022-04-11-aarch64-apple-darwin (overridden by '/Users/wiktorjurkiewicz/temps/rust-gpu-empty/rust-toolchain')
rustc 1.62.0-nightly (1f7fb6413 2022-04-10)

The example that you have provided does not compile on my setup:
cargo check:

   Compiling libc v0.2.131
   Compiling ahash v0.7.6
   Compiling sanitize-filename v0.4.0
   Compiling quote v1.0.21
   Compiling num-traits v0.2.15
   Compiling indexmap v1.9.1
error[E0658]: `const extern fn` definitions are unstable
   --> /Users/wiktorjurkiewicz/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/macros.rs:203:17
    |
203 | /                 pub $($constness)* extern fn $i($($arg: $argty),*
204 | |                 ) -> $ret {
205 | |                     $($body);*
206 | |                 }
    | |_________________^
    |
   ::: /Users/wiktorjurkiewicz/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/unix/bsd/mod.rs:572:1
    |
572 | / safe_f! {
573 | |     pub {const} fn WTERMSIG(status: ::c_int) -> ::c_int {
574 | |         status & 0o177
575 | |     }
...   |
591 | |     }
592 | | }
    | |_- in this macro invocation
    |
    = note: see issue #64926 <https://github.com/rust-lang/rust/issues/64926> for more information
    = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable
    = note: this error originates in the macro `safe_f` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: `const extern fn` definitions are unstable
    --> /Users/wiktorjurkiewicz/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/macros.rs:188:17
     |
188  | /                 pub $($constness)* unsafe extern fn $i($($arg: $argty),*
189  | |                 ) -> $ret {
190  | |                     $($body);*
191  | |                 }
     | |_________________^
     |
    ::: /Users/wiktorjurkiewicz/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/unix/bsd/apple/mod.rs:4758:1
     |
4758 | / f! {
4759 | |     pub fn CMSG_NXTHDR(mhdr: *const ::msghdr,
4760 | |                        cmsg: *const ::cmsghdr) -> *mut ::cmsghdr {
4761 | |         if cmsg.is_null() {
...    |
4793 | |     }
4794 | | }
     | |_- in this macro invocation
     |
     = note: see issue #64926 <https://github.com/rust-lang/rust/issues/64926> for more information
     = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable
     = note: this error originates in the macro `f` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: `const extern fn` definitions are unstable
    --> /Users/wiktorjurkiewicz/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/macros.rs:203:17
     |
203  | /                 pub $($constness)* extern fn $i($($arg: $argty),*
204  | |                 ) -> $ret {
205  | |                     $($body);*
206  | |                 }
     | |_________________^
     |
    ::: /Users/wiktorjurkiewicz/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/unix/bsd/apple/mod.rs:4796:1
     |
4796 | / safe_f! {
4797 | |     pub {const} fn WSTOPSIG(status: ::c_int) -> ::c_int {
4798 | |         status >> 8
4799 | |     }
...    |
4815 | |     }
4816 | | }
     | |_- in this macro invocation
     |
     = note: see issue #64926 <https://github.com/rust-lang/rust/issues/64926> for more information
     = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable
     = note: this error originates in the macro `safe_f` (in Nightly builds, run with -Z macro-backtrace for more info)

   Compiling syn v1.0.99
For more information about this error, try `rustc --explain E0658`.
error: could not compile `libc` due to 3 previous errors
warning: build failed, waiting for other jobs to finish...

[oisyn]

Ah aarch64, seems related to this bug: #890

[watjurk]

Okay, but I can't see how this should help us to resolve the general issue

[oisyn]

It doesn't, I was just thinking out loud ;)

[eddyb]

More specifically, it looks like it's the thing I mentioned in #890 (comment) (see rust-lang/libc@576f778#r80215910).

libc broke nightlies reporting as 1.62.0 - roughly speaking, because of the nightly->beta->stable "train" model, that means those nightly between stable 1.60.0 and 1.61.0 releases (though offset by like a week or so) - 1.61.0 was released on May 19, 2022, so updating to "early May" might be enough to get rid of this issue.

libc should not have done the version check in a way that's fragile wrt, but at this point I'm not sure it's worth fixing it on libc's end.

Wait, I know why @glandium said "early 1.62.0 nightlies" (emphasis mine), this stabilized it:

• Stablize const_extern_fn for "Rust" and "C" rust-lang/rust#95346

So based on this, we only need to rustup to 2022-04-18 to have it work, which may be much easier than May.

[watjurk]

So it seems like this issue is present, as far as I known, only on aarm toolchain

[oisyn]

As I already started working on getting the nightly up to date, the expectation is that this issue gets fixed automatically as soon as we're up to date far enough, which given @eddyb's comment doesn't seem too far in the future relative to 2022-04-11 so this will probably be very soon. So I'm inclined to leave this issue as-is for now. You have a workaround by pinning libc to 0.2.112.

[watjurk]

That works for me, thanks for clarification!

[eddyb]

Okay, before anyone wastes their time, this is not limited to aarch64, these are coincidences (just like #889, it's getting kind of ridiculous).

Try running cargo install cargo-apk inside the Rust-GPU directory (so that cargo install picks up our rust-toolchain) - this will try to build libc for your host and that's broken in the combination of new libc and the older nightly (regardless of what your host arch actually is, as long as it's Linux UNIX-y).

[watjurk]

I think this is not limited to Linux only, I'm using MacOS (Darwin) and this issue is present.

[eddyb]

Ah, my bad, I reacted to unix/linux_like in the errors but I suppose macOS might also hit that (or it's possible almost all OSes supported by the libc crate have their own extern const fn functions anyway).

[watjurk]

From curiosity I've started reading libc's readme, you could see that const-extern-fn is a feature so it should be possible to disable it, am I right?

[eddyb]

so it should be possible to disable it

@watjurk I don't think so, I remember it being force-enabled by its build.rs based on the rustc version.

[oisyn]

I was able to repro the issue locally under linux, and can confirm it goes away when building with nightly-2022-04-18.