-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
liballoc built with -Csplit-debuginfo=unpacked
despite not being supported on riscv32imc-unknown-none-elf
#112406
Comments
This looks to be like a bug in bootstrap here. It is checking for the build target and not the std target. Additionally, it is injecting split-debuginfo settings in RUSTFLAGS instead of using cargo profiles. I would suggest that bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it. Cargo already dynamically detects if split-debuginfo is supported on the platform. |
[bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement `@ehuss's` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
[bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement ``@ehuss's`` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
…rum,onur-ozkan [bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement `@ehuss's` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
Rollup merge of rust-lang#121754 - TimNN:split-target, r=Mark-Simulacrum,onur-ozkan [bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement `@ehuss's` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
I've only observed this on Mac hosts, not Linux. (Are we mixing up host and target somewhere?)
Given the following config.toml:
I get this error:
Rerunning with
-v
reveals that rustc is invoked with-Csplit-debuginfo=unpacked
.Verbose output
#110224 is related, but the resolution for that appears to be to fix the target definition. The definition for the riscv32imc target correctly lists the only supported option as
off
:So this might actually be a cargo bug. cc @ehuss
The text was updated successfully, but these errors were encountered: