Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo no longer passes RUSTFLAGS to build scripts, regression in 1.55.0 #10321

Closed
ColinFinck opened this issue Jan 24, 2022 · 6 comments
Closed
Labels
C-bug Category: bug

Comments

@ColinFinck
Copy link

Problem

I'm building a Rust project via the meta-rust layer in Yocto's BitBake build system for a target platform. Building via Yocto has the effect that vital RUSTFLAGS are set and exported before every call to cargo.
In my case, these are:

export RUSTFLAGS=" -L /drone/src/build-apu2/tmp/work/dbft3b-poky-linux/sparkd/git-r0/recipe-sysroot/usr/lib/rust --remap-path-prefix=/drone/src/build-apu2/tmp/work/dbft3b-poky-linux/sparkd/git-r0=/usr/src/debug/sparkd/git-r0"

This is working well for Cargo 1.54.0.
However, my project no longer builds when my Yocto build system is upgraded to Cargo 1.55.0 (and newer releases, tested up to 1.58.0). Instead, it fails with:

| error: failed to run custom build command for `num-bigint-dig v0.7.0`
|
| Caused by:
|   process didn't exit successfully: `/drone/src/build-apu2/tmp/work/dbft3b-poky-linux/app/git-r0/build/target/release/build/num-bigint-dig-c4db4ab7c1de662b/build-script-build` (exit status: 101)
|   --- stderr
|   error[E0463]: can't find crate for `std`
|     |
|     = note: the `x86_64-poky-linux` target may not be installed

num-bigint-dig 0.7.0 is the latest version of that crate and itself depends on autocfg 0.1.5. It comes with a build.rs file that runs ac.probe_type("i128"). This is where the build script fails with can't find crate for std.

Steps

No response

Possible Solution(s)

I have tracked down the problem to this line that got added between Cargo 1.54.0 and 1.55.0:

cmd.env_remove("RUSTFLAGS");

While that commit also adds a CARGO_ENCODED_RUSTFLAGS environment variable (which is probably a good idea), I don't see why you had to remove RUSTFLAGS from being passed to the build script.
Removing that line keeps RUSTFLAGS during invocation of the build script and fixes my problem.

Notes

No response

Version

No response

@ColinFinck ColinFinck added the C-bug Category: bug label Jan 24, 2022
@ColinFinck
Copy link
Author

I was told this is a duplicate of #10111. However, I'm unsure if the solution should really be to "fix" all crates that have been using RUSTFLAGS in their build scripts ever since.

For once, cargo is unsetting a previously available environment variable here. People rightfully expected a globally exported RUSTFLAGS variable to still be available when their build scripts are called (even if that variable never reflected other methods like build.rustflags).

And they have written their build scripts that way.
The popular autocfg crate by @cuviper, as just one example, uses RUSTFLAGS since 0.1.x. A quick glance at the dependencies of my project shows that both autocfg 0.1.x and 1.0.x are still actively used.
Someone would now need to release a new 0.1.x version and a new 1.0.x version. And the new releases would now need to check for both RUSTFLAGS and CARGO_ENCODED_RUSTFLAGS in order to not raise the minimum supported Rust version.

Is that really what was intended here?

@cuviper
Copy link
Member

cuviper commented Jan 24, 2022

Ah, I did intend to look for CARGO_ENCODED_RUSTFLAGS in autocfg, but it fell into my backlog. I wasn't thinking about the 0.1.x series, but that's possible. I might just make that re-export from 1.* like the semver trick, because there weren't any breaking changes anyway.

@ColinFinck
Copy link
Author

Hey @cuviper, thanks for your reply!
I've added support for CARGO_ENCODED_RUSTFLAGS in cuviper/autocfg#38

Would be great if you could have a look and release new 1.0.x and 0.1.x versions soon :)

@joshtriplett
Copy link
Member

@ColinFinck Unfortunately, we were faced with a difficult choice here: we were regularly seeing scripts experiencing breakage when people attempted to pass complex flags. Our choice was between "people experience breakage in unusual cases not seen in testing" and "people see the breakage right away in the common case, and fix it". We ended up opting for the latter. Sorry for the change that resulted in having to adapt build scripts.

@cuviper
Copy link
Member

cuviper commented Feb 8, 2022

Closing the loop on autocfg, I did publish 1.1.0 and 0.1.8 yesterday that will use CARGO_ENCODED_RUSTFLAGS.

@ColinFinck
Copy link
Author

@joshtriplett Thanks for the explanation!
My original problem has been fixed now that @cuviper has released autocfg 1.1.0 and 0.1.8. I can confirm that they are picked up during the Yocto build of my Rust application and it all compiles smoothly now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

3 participants