-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Latest nightly are failing to build non-toy projects at linking stage when using LTO optimization #108853
Comments
A few things you could try:
If the last suggestion helps, please mention this in rust-lang/compiler-builtins#491. |
I tested 1&2 and got: Compile error
(PS: I'm currently testing 3) |
Adding |
One more suggestion: ensure that
(Update the profile name as appropriate). |
Thank you, this fix the issue! Is this considered a regression or can we close the issue? |
The fact that we need to use a |
Is there a variant of this that demonstrates the problem described here without using any |
(if we can gain confidence that this always requires some |
FWIW, I see So even setting the present issue aside, it seems to me like we have a mismatch in the amount of use versus the amount of care or investment that's put into this behavior of this option. |
Yeah, even aside from embedded, I can only speak personally, but a very large number of the Rust projects I've worked on professionally (most of which are not embedded) compile with s or z, to help mitigate the size of compiled Rust code1. Either way, it would be good to test them in CI, although I can imagine that doing so might be painful. Footnotes
|
From what I tested this issue is (only) triggered by However please note that these flags are used by a lot of projects (even ones targeting |
WG-prioritization assigning priority (Zulip discussion). I wonder if a smaller reproducible can help (seems the topic of opt. flags is somewhat wide), tentatively setting that label either. @rustbot label -I-prioritize +P-high +E-needs-mcve |
I'm pretty sure the problem is that you are trying to use the unwinding panic runtime with I believe this is exactly the same issue as #107016 I do not really know why unwinding panics with |
As pointed out in my initial post, I removed tldr; this doesn't fix the issue |
Interesting. I can get linker errors when compiling RustHound and helix without (I'm only testing with |
Do you have the exact compile line used? It's important to note that this seems to only happen when cross-compiling. For example, let's take RustScan: Building for Compile error
Building for Compile error
I used those flags for compilation: OPTI_FLAGS="-C link-dead-code=n -C lto=fat -C opt-level=z -C embed-bitcode=yes -C panic=abort -C symbol-mangling-version=v0 -C codegen-units=1"
OPTI_ARGS="-Z build-std=core,std,panic_abort -Z build-std-features=panic_immediate_abort" Please also note that I confirm this worked prior to |
Work-around for [rust-lang/rust#108853][1] suggested [here][2]. Fixes undefined symbol errors in the `report-size` CI workflow. [1]: rust-lang/rust#108853 [2]: rust-lang/rust#108853 (comment)
This works around rust-lang/rust#108853 by using an `opt-level` of `3` rather than `s`. - [x] Changelog updated / no changelog update needed
FWIW this does not work for me; maybe b/c I'm part of a workspace, when I put this at the top-level This issue is essentially a showstopper bug for my msp430 work, so even a working unstable solution to reenable LTO like above will unblock me. If I have time, I'll do my own bisection; for some reason I'm unable to duplicate this bug on Linux on the same codebase with a nightly that's a week or two behind Windows. |
Hi, here some precision about the workarounds:
[unstable]
profile-rustflags = true
[profile.release.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"] Even if you use a workspace, you need to place this file in the root folder (more info here). If you don't want to edit any file, for both solutions you can pass these options using the command line:
|
Okay, so the reason I got confused is: if [profile.examples-fix]
inherits = "examples"
[profile.examples-fix.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]
[unstable]
profile-rustflags = true AFAICT, The [profile.examples]
inherits = "release"
lto = "fat"
opt-level = "s"
codegen-units = 1 Adding a separate profile in |
I did my own bisect tonight on my own codebase, thinking it was incredibly weird that this specific commit broke LTO. But alas, I can confirm from my bisection that this is the exact commit where everything broke. I can't help but wonder if this is an LLVM bug in disguise, and this commit simply triggered an existing bug. But it's late right now, so I'll have to test that theory later. |
Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
After updating to the latest version of Rust, I found that many of my projects are failing to compile at linking stage when doing size-optimized builds (cf. https://github.com/johnthagen/min-sized-rust). I found the possible nightly-to-nightly regression to be from
nightly-2023-02-27
tonightly-2023-02-28
. This seems to be a real issue since min-sized builds are widely used. Also I failed to reproduce this in a toy project.To trigger that "bug" I used these compiler flags:
Possible linked issues:
core::panicking::panic
compiler-builtins#347I tried to build those projects with the latest working nightly (
nightly-2023-02-27
) and the first non-working nightly (nightly-2023-02-28
):I expected to see this happen: build succeed in both cases.
Instead, this happened: linker errors on the first non-working nightly (
nightly-2023-02-28
) and compile success with the latest working nightly (nightly-2023-02-27
). This show a possible regression.For RustHound (using
nightly-2023-02-28
):Compile error
For RustScan (using
nightly-2023-02-28
):Compile error
For Helix (using
nightly-2023-02-28
):Compile error
Please note that I used windows cross compilation builds as an example,
but same thing can happen with other targets (even when not cross-compiling). Also note that the linking errors can be different regarding the selected target.After some more tests with Linux (and checking this issue), I found that we need to add
-C panic=abort
to overpass another linking issue (cf. #107016 (comment)). This doesn't resolve the issue for Windows cross-compilation however.The text was updated successfully, but these errors were encountered: