-
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
GNU linker warns “corrupt .drectve” on staticlib binary generated with Rust 1.70 on Windows #112368
Comments
Looks like support for the Those changes were released in Binutils 2.40 (the latest) and LLVM 15, both fairly new versions. GNU ld < 2.40 will emit a warning if it sees this directive, and lld < 15 will fail to link. |
Thank you so much! It really helps. In our particular use case, we use a toolchain called Rtools, which is provided for compiling R packages, and, fortunately, the latest version of it uses binutils 2.40.
Actually, I confirmed I don't see these warnings after I updated the toolchain to the latest version (I didn't notice there's a newer version). So, this might be a less serious problem than I thought at first. I'm not sure if it's fine in general to require such a new version of binutils, though. |
@rustbot label -regression-untriaged +regression-from-stable-to-stable |
FWIW, I'm running into this issue with lld 14 and I'm definitely not a good position to trivially upgrade to lld 15+ (though I guess if I stick with 1.69.0 for another year or so the maintainers of my toolchain packages will manage to release one based on lld 15). |
I'm using the GNU LD linker for two reasons:
I too started seeing the warnings detailed above after upgrading the nightly version of rust I'm using. Example warnings from gnu ld 2.34. (arm-none-eabi) and gnu ld 2.39.
At the time of writing the latest official GNU Arm Tools is 12.2.MPACBTI-Rel1 https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads which give you this version:
which is 2.40. However, I still see all the warnings, as follows:
It's thus not correct to say that "GNU < 2.40" (see #112368 (comment)) will emit warnings, as I guess I'll have to wait for a new GNU Arm Tools release or build windows binaries somehow, neither of which are appealing. 😄 |
When you use a |
It's harmless warning. Previously binaries would contain unnecessary symbols and this newly introduced feature gets rid of them. Like already said here it's supported by GNU toolchain (since Binutils 2.40)
Most importantly artifacts produced by Rust and GNU toolchain (GCC+Binutils+mingw-w64) are compatible with each other. Linking and the resulting binaries still work but a warning is shown when Binutils are too old to support feature used by LLVM. Surely this is not ideal (maybe there is a way to silence this warning from
2.40 does contain the required changes, either you have some environment issue or their version is not 2.40.
When speaking of windows-gnu target it's never about glibc but a GNU toolchain so GCC and Binutils (or compatible one like LLVM) coupled with MinGW. |
Thanks for the detailed explaination!
I now agree with you. Since my problem is almost solved, I'm fine to close this issue. The only two reasons I keep this open are (1) I don't have enough knowledge to judge if this is a negligible issue (2) those who suffer from this warning might find this easier. Should I close this issue? Regarding #112368 (comment), I also confirmed 2.40 contains the required change. So, it seems it's a problem on Arm's GCC toolchain's side, not on Rust's side. |
It might be worth to keep it open for the compiler team to decide though. |
Sure, let's keep this open for a while. |
Same here, ucrt64 environment, versions as follows.
However, I do cross-compilation, I'm compiling for various ST Arm MCUs, and it looks like the version of 'arm-none-eabi-ld' is < 2.4.0, so I'm probably seeing warnings from that version of 'ld'.
|
@hydra so those warnings appear when cross-compiling from I think those directives shouldn't be used for targets other than Windows. Does it also happen when building from different host triple? |
That said, I just tried with this version, the latest GNU Arm Tools release:
And still see errors, as below:
It is 2.40.0.20230307, there are no other 'ld' instances in my path.
yes, as follows: rustup:
Don't know, and I don't have any specific code to test that scenario. If you have example command lines/projects for me to compile let me know and I can try for you. Suggestions? |
As a further update to this, since the linker output now contains all the warnings, I just had to scroll back past 2800 (!!!) lines of warnings to get to the error message that caused by build to fail. I suspect the size of build logs on CI servers will be filling up disks much quicker now too. It's making things very unworkable here. |
Is anyone working on this? Can we get it assigned to be worked on? Currently actual error messages get buried in the output, making development /extremely/ painful. |
@hsn10 Rust doesn't call ld.bfd directly but instead relies on GCC ( |
rustc needs what exe in path? that x86_64-w64 .. -gcc which comes bundled with rust? because in my gcc 13 installation x86_64-w64-mingw32 is a directory with (ar.exe, ld.exe, as.exe, nm.exe, ld.bfd, etc), not single exe file. |
|
Its probably designed to work with this https://github.com/niXman/mingw-builds-binaries/releases mingw distribution. This is most passive distro and it will take a while until they upgrade gnu linker. Other distros are more active. I am using this: |
The last several comments are about a completely different issue, and binutils has released 2.42 (issue fixed in 2.40). I think this can be closed. |
Rust still ships very old Binutils so this issue is not fixed. |
I've seen this reproduce with Binutils 2.42 and GCC 14.1.0 (I built the toolchain based on MSYS2's specs, with the host being |
Either there must have been some other toolchain in your PATH or Binutils have regressed. I haven't seen this problem with MSYS2 toolchains. |
Can reproduce this error on https://github.com/ZNotify/cli/actions/runs/10145751720/job/28052213372 |
@Zxilly this warning doesn't cause build failures. In your case the linker has crashed, I'd suggest trying with different version. |
@mati865 Thanks, but I didn't have any fixes in mind, so I simply removed the gnu target. This issue came up after the 1.70 release, but I can't reproduce it locally. |
You probably have a different Binutils version locally and it doesn't crash. |
For binutils I have 2.42 locally, and https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md shows the CI have the binutils 2.39. I'll continue to delve into this when I can. |
rust won't pick locally installed binutils automatically because auto detection code there can detect only one special distribution and that distribution ships outdated binutils. |
Rust will pick any linker from the PATH that is named |
Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang#112368 try-job: i686-mingw try-job: x86_64-mingw
Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang#112368 try-job: i686-mingw try-job: x86_64-mingw
…jieyouxu,petrochenkov Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang#112368
…jieyouxu,petrochenkov Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang#112368
…jieyouxu,petrochenkov Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang#112368
…jieyouxu,petrochenkov Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang#112368
Rollup merge of rust-lang#119229 - mati865:update-mingw-toolchain, r=jieyouxu,petrochenkov Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang#112368
…petrochenkov Update mingw-w64 + GNU toolchain The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0 Fixes: rust-lang/rust#112368
It seems, as of version 16, LLVM generates a binary containing incompatible directive with GNU linker. I believe this is the cause:
commit: llvm/llvm-project@c5b3de6
Since Rust 1.70 upgraded LLVM to version 16, we started to see a lot of warnings by GNU linker when I link against staticlibs compiled by Rust. The warnings are like this:
It seems I can just ignore this warning (while the concern described in the LLVM's commit can be a real problem in future), but still I feel this is something that should be fixed if possible. I know, from LLVM's viewpoint, it's reasonable to assume the linker is lld and embed the directives that only lld can understand. But, on the other hand, from Rust's viewpoint, is it intentional that the "GNU" target produces a binary that is incompatible with "GNU" linker? I'm honestly not sure about the answer. I'm yet to figure out what the "GNU" in Rust's GNU toolchain/target actually means.
Code
A minimal reproducible code: https://github.com/yutannihilation/rust170_gnu_warning
In case of Rust 1.69, we don't see any warnings. However, if it's compiled using Rust 1.70, GNU linker warns:
(This can be reproducible on GHA: result)
Version it worked on
It most recently worked on: Rust 1.69
Version with regression
rustc --version --verbose
:Backtrace
References
The text was updated successfully, but these errors were encountered: