Skip to content

build.rs should ignore RUSTFLAGS  #6375

New issue
New issue
Open
Open
build.rs should ignore RUSTFLAGS #6375
Labels
A-build-scriptsArea: build.rs scriptsA-configurationArea: cargo config files and env varsA-environment-variablesArea: environment variablesA-rustflagsArea: rustflagsS-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Description

@polachok
polachok
opened on Dec 4, 2018

Problem

build.rs is compiled with RUSTFLAGS if target is not specified.

$ RUSTFLAGS="-C target-cpu=nehalem" cargo build -vv
   Compiling test-build v0.1.0 (/Users/plhk/Documents/src/test-build)
     Running `rustc --crate-name build_script_build build.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=8a72131a02621b95 -C extra-filename=-8a72131a02621b95
 --out-dir /Users/plhk/Documents/src/test-build/target/debug/build/test-build-8a72131a02621b95 
-C incremental=/Users/plhk/Documents/src/test-build/target/debug/incremental
-L dependency=/Users/plhk/Documents/src/test-build/target/debug/deps -C target-cpu=nehalem`

The problem here is that if a user compiles for a newer CPU than they have, build script can potentially use newer instructions and fail with SIGILL.

Steps
1.cargo new test-build
2.cd test-build
3.touch build.rs
4.cargo build -vv

Possible Solution(s)
I don't have a solution, but it seems like env_args() is the problem.

Notes

Output of cargo version:

cargo 1.30.0 (a1a4ad3 2018-11-02)

Activity

  1. alexcrichton commented on Dec 6, 2018

    @alexcrichton
    alexcrichton
    on Dec 6, 2018
    Member

    As a workaround I'd recommend passing --target which will disable this behavior. Otherwise this is a well known issue covered by a number of other issues too: #3349, #4423, #5754

  2. alexcrichton
    added
    A-build-scriptsArea: build.rs scripts
    on Dec 6, 2018
  3. ehuss
    added
    A-environment-variablesArea: environment variables
    A-configurationArea: cargo config files and env vars
    on Nov 8, 2019

  4. elichai commented on Dec 1, 2019

    @elichai
    elichai
    on Dec 1, 2019

    I'm still getting error: lto can only be run for executables, cdylibs and static library outputs sometimes even when passing --target
    example:
    command: RUSTFLAGS+=' -Clto -Ctarget-cpu=native' cargo install --force cargo-crev --target x86_64-unknown-linux-gnu --verbose

    output:

         Running `sccache rustc --crate-name openssl_sys /home/elichai2/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.53/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C metadata=80e051d4886f40ee -C extra-filename=-80e051d4886f40ee --out-dir /tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps -L dependency=/tmp/cargo-installplOv5W/release/deps --extern libc=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/liblibc-f9604e2813c04637.rmeta --cap-lints allow -Clto -Ctarget-cpu=native --cfg const_fn --cfg 'osslconf="OPENSSL_NO_SSL3_METHOD"' --cfg ossl101 --cfg ossl102 --cfg ossl102f --cfg ossl102h --cfg ossl110 --cfg ossl110f --cfg ossl110g --cfg ossl111 --cfg ossl111b --cfg ossl111c -l ssl -l crypto`
     Running `/tmp/cargo-installplOv5W/release/build/libssh2-sys-da404dcad10cbb4b/build-script-build`
     Running `/tmp/cargo-installplOv5W/release/build/openssl-9d46d869025e0183/build-script-build`
     Running `/tmp/cargo-installplOv5W/release/build/native-tls-768c28bd77a5ca54/build-script-build`
error: lto can only be run for executables, cdylibs and static library outputs

error: aborting due to previous error

error: could not compile `miscreant`.

Caused by:
  process didn't exit successfully: `sccache rustc --edition=2018 --crate-name miscreant /home/elichai2/.cargo/registry/src/github.com-1ecc6299db9ec823/miscreant-0.4.2/src/lib.rs --color never --crate-type rlib --crate-type staticlib --emit=dep-info,link -C opt-level=3 --cfg 'feature="aes"' --cfg 'feature="alloc"' --cfg 'feature="byteorder"' --cfg 'feature="default"' --cfg 'feature="soft-aes"' --cfg 'feature="std"' --cfg 'feature="stream"' -C metadata=eb7b7ea891b79345 -C extra-filename=-eb7b7ea891b79345 --out-dir /tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps -L dependency=/tmp/cargo-installplOv5W/release/deps --extern aes=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libaes-59bc26c48e377af1.rlib --extern aesni=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libaesni-b0a0a29efbc7f08e.rlib --extern byteorder=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libbyteorder-379311baed87428e.rlib --extern cmac=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libcmac-51c758923f362247.rlib --extern crypto_mac=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libcrypto_mac-c71872e5c18ce69b.rlib --extern ctr=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libctr-840349a39310199e.rlib --extern dbl=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libdbl-3fb84d3a157ed756.rlib --extern generic_array=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libgeneric_array-075965c8c4c8ace9.rlib --extern pmac=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libpmac-d83af01cf6d8859c.rlib --extern stream_cipher=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libstream_cipher-701a688a1df56cd4.rlib --extern subtle=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libsubtle-7d7c1d3bbdcf00ab.rlib --extern zeroize=/tmp/cargo-installplOv5W/x86_64-unknown-linux-gnu/release/deps/libzeroize-afe337c85ef76089.rlib --cap-lints allow -Clto -Ctarget-cpu=native` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-crev v0.13.0`, intermediate artifacts can be found at `/tmp/cargo-installplOv5W`

Caused by:
  build failed

    full output: https://pastebin.com/raw/0fPA4Mhz

  5. ehuss commented on Dec 1, 2019

    @ehuss
    ehuss
    on Dec 1, 2019
    Contributor

    @elichai It looks like miscreant specifies multiple crate types (rlib/staticlib). LTO doesn't support that. You need to specify lto in the Cargo profile so that Cargo will handle passing the flag at the correct time.

  6. elichai commented on Dec 1, 2019

    @elichai
    elichai
    on Dec 1, 2019

    @elichai It looks like miscreant specifies multiple crate types (rlib/staticlib). LTO doesn't support that. You need to specify lto in the Cargo profile so that Cargo will handle passing the flag at the correct time.

    How can I do that without editing Cargo.toml? (i.e. I have a script that adds ' -Clto -Ctarget-cpu=native' to all of my installs)

  7. ehuss commented on Dec 1, 2019

    @ehuss
    ehuss
    on Dec 1, 2019
    Contributor

    Config profiles support that, but unfortunately they are unstable/unfinished.

    CARGO_PROFILE_RELEASE_LTO=true cargo install foo -Zconfig-profile

  8. ehuss
    added
    A-rustflagsArea: rustflags
    on Apr 6, 2020
  9. lu-zero
    added 2 commits that reference this issue on May 26, 2020

    Update nightly in CI

    714fdb6

    Update nightly in CI

    6e88ea2
  10. shssoichiro
    added a commit that references this issue on May 28, 2020

    Update CI (#2329)

    5ee1e71
  11. lu-zero
    added 2 commits that reference this issue on May 28, 2020

    Update CI (xiph#2329)

    a25f3c3

    Update CI (#2329)

    9a59a25
  12. toku-sa-n
    added 3 commits that reference this issue on Jun 29, 2021

    chore(init): specify a target explicitly

    ef4a4f3

    chore(kernel): avoid to compile `build.rs` wrongly

    82c4a4e

    chore(kernel): avoid to compile `build.rs` wrongly (#84)

    09522e8

  13. andrewbaxter commented on Feb 7, 2023

    @andrewbaxter
    andrewbaxter
    on Feb 7, 2023

    For anyone else who hits the issue, the workaround is to

    1. Specify RUSTFLAGS as an environment variable when invoking cargo and
    2. Specify --target, which disables using the env var for build.rs (it will be used for building the binary).

    Note that this does not work with rustflags = [...] in cargo/config.toml AFAICT, it must be done with the environment variable.

  14. mert-kurttutan commented on Jun 7, 2023

    @mert-kurttutan
    mert-kurttutan
    on Jun 7, 2023

    Here I am putting a minimal example I have that gives this problem (that is reproducible on a Ubuntu machine, rustc rustc 1.70.0) in case someone finds it useful:

    // build.rs                                                                         
fn main(){
    println!("Hello world!");
    let version = "rustc 1.70.0 1-(05".to_owned();
    let nightly = version.contains("dev");
    println!("End of world!");
}
    // .cargo/config.toml
[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "target-feature=+avx512f"]

    The problem goes away if you change version to

    let version = "rustc 1.70.0 1-".to_owned();
  15. epage
    added
    S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
    on Oct 25, 2023
  16. link2xt
    added a commit that references this issue on Apr 4, 2024

    Enable LTO via `cargo` profile setting

    2d303fb

  17. usamoi commented on Jul 16, 2025

    @usamoi
    usamoi
    on Jul 16, 2025
    Contributor

    I've been stumped by this problem at least three times.

    • When the machine doesn't support AVX512, enabling AVX512 with RUSTFLAGS causes the build script to receive an illegal instruction fault.

    • When enabling PGO using -Cprofile-generate and using a relative path for the profile data, every crate's build script generated its own garbage data in its manifest directory, including dependencies in ~/.cargo/registry/src.

    • When cross-compiling on a musl host, libclang cannot be dynamically linked, which makes bindgen fail. There is no way to pass rustflags to build scripts. When I needed this bug, it unexpectedly behaved correctly.

    I believe we absolutely don't need this strange behavior, especially since it's inconsistent between cross-compilation and native compilation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-build-scriptsArea: build.rs scriptsA-configurationArea: cargo config files and env varsA-environment-variablesArea: environment variablesA-rustflagsArea: rustflagsS-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions