Cannot compile with rust 1.70 and x86_64-unknown-linux-musl target

[nicolaspernoud]

Hello,

I get the following error :

#0 33.24 error[E0061]: this function takes 3 arguments but 2 arguments were supplied
#0 33.24    --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/getrandom-0.1.16/src/util_libc.rs:113:14
#0 33.24     |
#0 33.24 113 |     let fd = open(path.as_ptr() as *const _, libc::O_RDONLY | libc::O_CLOEXEC);
#0 33.24     |              ^^^^------------------------------------------------------------- an argument of type `u32` is missing
#0 33.24     |
#0 33.24 note: function defined here
#0 33.24    --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/libc-0.2.145/src/unix/linux_like/linux/musl/lfs64.rs:112:26
#0 33.24     |
#0 33.24 112 | pub unsafe extern "C" fn open64(
#0 33.24     |                          ^^^^^^
#0 33.24 help: provide the argument
#0 33.24     |
#0 33.24 113 |     let fd = open(path.as_ptr() as *const _, libc::O_RDONLY | libc::O_CLOEXEC, /* u32 */);
#0 33.24     |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#0 33.24 

It works fine with 1.69 .

[newpavlov]

I can not reproduce it. Can you clear your Cargo cache and try again? I am using the following code for testing:

fn main() {
    let mut buf = [0u8; 32];
    getrandom::getrandom(&mut buf).unwrap();
    println!("{buf:?}");
}

If the error persists, then I think you should create an issue in the rust-lang/rust repository, since it looks like a compiler regression. After a cursory search I was unable to find a similar issue.

open uses C variadics, so the third argument is optional. But for some reason instead of using this definition, you get open which is an alias for open64.

[lu-zero]

The problem seems related to libc-0.2.145

[newpavlov]

The snippet was compiled with libc v0.2.145. Also, I have linked master branch which is currently equivalent to v0.2.145 regarding the open/open64 parts.

Please provide a minimal reproducible example.

[nicolaspernoud]

I am sure it is not Cargo cache related, since I build it in a Docker container, I will try to provide an example

[can-arikan]

I suffer from the same issue, i may also approve that he issue is not related to cargo since i'm also building in Docker container

[ndmitchell]

I see exactly the same issue. https://github.com/facebook/buck2/actions/runs/5174587176/jobs/9321086346 for our public link to the failing job. I confirm that pinning libc fixes the issue.

[newpavlov]

Ah, the issue is triggered only with getrandom v0.1 (I thought it was about v0.2), due to this cfg:

cfg_if! {
    if #[cfg(any(target_os = "linux", target_os = "emscripten"))] {
        use libc::open64 as open;
    } else {
        use libc::open;
    }
}

IIUC before v0.2.145 open64 was using variadics on MUSL, so it looks like the root issue is with breaking change in libc. So I think you should report it to their repository. But I am not sure why it works fine on Rust 1.69.

As a side note: you probably should nudge the dependencies which pull getrandom v0.1 (probably through rand) to update their dependencies or replace them with alternatives.

[nicolaspernoud]

Actually, it fails as well with 1.69, it was just random hasard that it failed when I upgraded to 1.70. I will try to nudge the dependencies as advised.

[newpavlov]

I have created libc issue, see: rust-lang/libc#3264

[nicolaspernoud]

Thanks, let's see if that solves it for the time being : walking back the dependency tree to update everything to 0.2 will take some time...

[newpavlov]

As a temporary workaround it should be sufficient to downgrade libc to v0.2.144. Hopefully, v0.2.146 will fix the issue.

[nicolaspernoud]

I will do that. Thanks a lot !

[CommanderStorm]

As a temporary workaround it should be sufficient to downgrade libc to v0.2.144. Hopefully, v0.2.146 will fix the issue.

For those not well versed in cargo update:

cargo update -p libc --precise 0.2.144

Thank you for debugging it ❤️

[newpavlov]

libc v0.2.145 got yanked, so this issue should be resolved.

[nicolaspernoud]

Thanks for the information, and for your help !