Repository navigation
I think there might be a bug with the version matching #3052
Description
Activity
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()?)Ah check, that's inconvenient.
Thanks for the fix!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
bindgenrun.
Why would bindgen not be able to know what Rust version it targets, through the version of thecargoprocess launching it?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
bindgenwould not see any toolchain more recent than 1.77... shouldn't the version check in #3015 indeed avoid the newer construct?Why would bindgen not be able to know what Rust version it targets, through the version of the
cargoprocess launching it?See #3049 (comment)
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
bindgenrun.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 therustcpath from the cargo env vars and then runrustc --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 arust-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.
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.
Erf, that CLI option already exists...
How about changing RustTarget::default to return the version of the rust compiler in use when the __cli feature is not enabled?
- added a commit that references this issue
on Feb 10, 2025 We hit this in Fedora Linux too now - with bindgen-cli 0.71.1 compiled for EPEL on RHEL 9, it still defaults to generating code for Rust 1.82, whereas both the version it was compiled and the current version of Rust are 1.79. Defaulting to a Rust version that is newer than the version the executable was compiled with seems ill-advised.
Originally posted by @Kriskras99 in #3015 (comment)