I think there might be a bug with the version matching

[pvdrz]

I think there might be a bug with the version matching:

error: extern block cannot be declared unsafe
    --> /home/christiaan/scate2-dev/rust/target/release/build/flexnet_client-sys-a77799b3d52b9432/out/bindings.rs:3363:1
     |
3363 | unsafe extern "C" {
     | ^^^^^^
     |
     = note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information

error: extern block cannot be declared unsafe
    --> /home/christiaan/scate2-dev/rust/target/release/build/flexnet_client-sys-a77799b3d52b9432/out/bindings.rs:3371:1
     |
3371 | unsafe extern "C" {
     | ^^^^^^
     |
     = note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information

error: could not compile `flexnet_client-sys` (lib) due to 243 previous errors
warning: build failed, waiting for other jobs to finish...
christiaan@CBHST34:~/scate2-dev/rust$ rustc --version
rustc 1.81.0 (eeb90cda1 2024-09-04)

This is with bindgen = { version = "0.71.1" }

Originally posted by @Kriskras99 in #3015 (comment)

[pvdrz]

This is because bindgen automatically targets the latest rust available as it has no way to detect the rust version of your project (yet). So you have to set the version using builder.rust_target("1.81.0".parse()?)

[Kriskras99]

Ah check, that's inconvenient.
Thanks for the fix!

[pvdrz]

If you're using a rust-toolchain.toml file: #3049

[ydirson]

This hardly looks like a fix. When you're building a project that use a crate that uses bindgen (quite common in fact), your project does not have any control over the bindgen run.
Why would bindgen not be able to know what Rust version it targets, through the version of the cargo process launching it?

[ydirson]

BTW, I'm curious what algorithm is used to select the target Rust version: when building inside docker.io/library/rust:1.77-buster, I would expect that bindgen would not see any toolchain more recent than 1.77... shouldn't the version check in #3015 indeed avoid the newer construct?

[ydirson]

Why would bindgen not be able to know what Rust version it targets, through the version of the cargo process launching it?

See #3049 (comment)

[pvdrz]

This hardly looks like a fix. When you're building a project that use a crate that uses bindgen (quite common in fact), your project does not have any control over the bindgen run.

Using bindgen in a crate is an implementation detail. If the crate you're using asserts that they have a specific MSRV and they don't, that's a bug in the crate. If they don't have a MSRV, then they just don't.

Why would bindgen not be able to know what Rust version it targets, through the version of the cargo process launching it?

Well, basically because there is no canonical way to know this, you can maybe grab it from the rust-toolchain.toml, or from the cargo manifest, or from the cargo env vars, or get the rustc path from the cargo env vars and then run rustc --version. Each one of these options has the caveat where some user won't be able to use it: Either their project doesn't have a rust-toolchain.toml, or they don't set a version in the manifest, or they don't even use cargo.

And that's for the users that actually use bindgen as a library, a lot of people just use the standalone CLI application.

[glandium]

a lot of people just use the standalone CLI application.

How many really use it standalone, as opposed to driven by the library? The library, when it's not using the CLI, could just use the rustc version it's being compiled with, via rustc_version, rustversion or similar crate. The library, when it is using the CLI, could pass the rustc version it's being compiled with to the CLI as an argument. And for the people that do use the CLI entirely in standalone mode, bindgen could default to the most recent version, and those people could also use the version flag to give a specific rust version if they so want.

[glandium]

Erf, that CLI option already exists...

[glandium]

How about changing RustTarget::default to return the version of the rust compiler in use when the __cli feature is not enabled?