GNU linker warns “corrupt .drectve” on staticlib binary generated with Rust 1.70 on Windows

[yutannihilation]

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:

Warning: .drectve `-exclude-symbols:_ZN7testpkg11hello_world17ha68eef8a416aa303E ' unrecognized
Warning: corrupt .drectve at end of def file

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

# compile Rust code to create a staticlib
cargo build --target=x86_64-pc-windows-gnu --lib --release

# compile the C code
gcc -c main.c -o main.o

# link to the staticlib
gcc -o testpkgrust170_gnu_warning.dll main.o -L./target/x86_64-pc-windows-gnu/release -lrust170_gnu_warning -lws2_32 -ladvapi32 -luserenv -lbcrypt -lntdll 

In case of Rust 1.69, we don't see any warnings. However, if it's compiled using Rust 1.70, GNU linker warns:

Warning: corrupt .drectve at end of def file
Warning: corrupt .drectve at end of def file

(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:

rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-pc-windows-msvc
release: 1.70.0
LLVM version: 16.0.2

Backtrace

References

• the original context: Fix compile error on Windows with Rust 1.70 extendr/rextendr#285 (comment)
• post on the Rust user forum before reporting here: https://users.rust-lang.org/t/corrupt-drectve-warning-on-x86-64-pc-windows-gnu-target-with-rust-1-70/94912

[erikdesjardins]

Looks like support for the -exclude-symbols .drectve was added to GNU ld in this commit, and then added to lld in these two commits.

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.

[yutannihilation]

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.

These packages have been updated:

(...snip...)
binutils 2.39 to 2.40
(https://cran.r-project.org/bin/windows/Rtools/rtools43/news.html)

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.

[Jules-Bertholet]

@rustbot label -regression-untriaged +regression-from-stable-to-stable

[saurik]

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).

[hydra]

I'm using the GNU LD linker for two reasons:

1. Because the normal linker hangs 9/10 times - See Linker hangs with no output 9/10 times. #88704
2. Because the normal linker doesn't have the ability to do some things in the way I want for embedded development, so I use arm-none-eabi-ld.

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.

Warning: .drectve `-exclude-symbols:"_ZN77_$LT$alloc..raw_vec..RawVec$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$4drop17hb89ba7c74cb66113E" ' unrecognized
Warning: .drectve `-exclude-symbols:"_ZN5alloc7raw_vec19RawVec$LT$T$C$A$GT$7reserve21do_reserve_and_handle17heb762ccf93d8463bE" ' unrecognized
Warning: corrupt .drectve at end of def file

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:

GNU ld (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 2.40.0.20230307

which is 2.40.

However, I still see all the warnings, as follows:

Warning: .drectve `-exclude-symbols:"_ZN77_$LT$alloc..raw_vec..RawVec$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$4drop17hb89ba7c74cb66113E" ' unrecognized
Warning: .drectve `-exclude-symbols:"_ZN5alloc7raw_vec19RawVec$LT$T$C$A$GT$7reserve21do_reserve_and_handle17heb762ccf93d8463bE" ' unrecognized
Warning: corrupt .drectve at end of def file

It's thus not correct to say that "GNU < 2.40" (see #112368 (comment)) will emit warnings, as 2.40.20230307 certainly still emits them.

I guess I'll have to wait for a new GNU Arm Tools release or build windows binaries somehow, neither of which are appealing. 😄