arm-none-eabi-ld not working with v0.3.8 #49
Comments
|
That looks like ThinLTO breakage. I thought that was already fixed; perhaps they changed something else? Does the program link when compiling in release mode? Could you try disabling ThinLTO? IIRC, you'll have to add |
|
It is compiling and linking in release mode. I tried to compile in debug mode with the -Z thinlto=n, it did not worked. I have the same error. |
|
OK, this is actually caused by incremental compilation being enabled by default on unoptimized builds. (I was looking at the wrong place: I bisected and was looking at rustc changes but the incremental stuff was done on the Cargo side -- I did notice a bunch of incremental artifacts appear on the BAD side of the bisect). @clebi You can disable incremental compilation by adding these lines to your Cargo.toml: [profile.dev]
incremental = falseI've known since long that incremental compilation breaks embedded programs in horrible ways (i.e. at link time) so the recommendation has been to not use when it was opt-in; I had no idea it was already considered stable enough to be enable by default. Honestly, the linker error shown above looks much less worse than I recall seeing before but unfortunately I have no time to investigate further right now. cc @alexcrichton (just to make you aware) |
|
I have disabled the incremental compilation like you said and there is still the same error. |
|
@clebi Try $ tree target
└── thumbv7m-none-eabi
└── debug
├── incremental
│ └── blue_pill-2xtd0v90b49rb
│ ├── s-eww3bret4k-1tl2y90-h8om2iji9y08
│ │ ├── cgu-blue_pill-afio.bc-compressed
│ │ ├── cgu-blue_pill-afio.o
|
|
I did the cargo clean. When I execute I checked the tree and the incremental folder is empty. The program I am building is there if it can be of any help. It does not contain all the steps you told me to do. |
Oh, that sounds like you have nightly-2017-12-24 or older. Incremental has not been enabled by default in those nightlies. I can repro your problem using your repository; it seems to be caused by the now default use of multiple codegen units. I though we fixed something related to that some time ago but maybe it was for the release profile (thinLTO). In any case you can workaroud the issue by using a single codegen unit: add this to Cargo.toml: [profile.dev]
codegen-units = 1 |
|
It works with a single codegen unit. I saw the bug first on rustc 1.24.0-nightly (77e189cd7 2017-12-28) and today on rustc 1.24.0-nightly (2dad872a2 2017-12-29). Thank you for the help fixing my build. |
|
As a stopgap solution cortex-m-quickstart v0.2.2 has incremental compilation and parallel codegen disabled in the dev profile. The actual root of the issue is rustc bug (cf. rust-lang/rust#47074) so I'm closing this since it's being tracked upstream (and it should get fixed Soon (TM)). |
|
Thanks, I was porting examples of latest cortex-m-rtfm to a different device crate, so I did not have a thorough look on quickstart crate this time. Maybe a silly question, if you have time to answer: I know that rtfm examples successfully build in debug. |
The issue appears to be totally random. It shows up in some projects but not in others. I think it depends on how the compiler ends up partitioning crates into smaller (LLVM) "modules" that then get worked on it parallel (when parallel codegen is enabled). |
Hello,
I have updated to version 0.3.8 of this crate to avoid this issue : ICE when trying to cross compile with xargo.
It now compiles but it seems there is a problem when linking.
I am using the cortex-m-rtfm framework and stm32f3disovery board. I use the f3 crate (latest git) and I was successful compiling the exact same program before.
It seems the problem is coming from interrupts. I have the following interrupts setup : I2C1_EV_EXTI23 and I2C1_ER. When I remove all interrupts, program compiles and links successfully.
Here is the nightly I am using : rustc 1.24.0-nightly (77e189cd7 2017-12-28)
This is the ld output :
The text was updated successfully, but these errors were encountered: