Tracking Issue for enabling the `linker-messages` lint by default

[jyn514]

This is a tracking issue for the linker-messages lint.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Allow the lint by default until it's less noisy: Downgrade linker-warnings to allow-by-default #136098
• Split the lint into linker-info and linker-messages. The former should be allow by default, and should contain things we know aren't actually an issue (at least not enough to warn by default). The latter includes everything else. See below for a detailed list of known linker warnings.
• Do a crater run to see if there's any other noisy output we should silence. This unfortunately will only give us info about x64 linux gnu, but it's better than nothing. Maybe we can do a few runs, one with each of ld, lld, mold, and ld.gold.
• Make linker-messages warn by default again.

Ideally, I would also like to post-process these messages and add more context about why they happen. For example, the MACOSX_DEPLOYMENT_TARGET warning should contain context about what a deployment target is and how it gets set. We could even go so far as to map back from symbol names and object files to the original Span and crate that caused a warning.

---

Known Warnings (should be silenced)

• MacOS LD: "ignoring duplicate libraries" (e.g. linker failure on macOS when building Miri: "linker stderr: ld: ignoring duplicate libraries" #136086 (comment)). This should just be silenced, it doesn't indicate anything is wrong.
• MacOS LD: "built for newer 'macOS' version than being linked". This is tracked by macOS deployment target defaults differ between rustc, cc-rs and clang #136113 and should be silenced until that issue is resolved.
• Windows MSVC link.exe: "Creating library ...". This should just be silenced, it's a progress message that can't be disabled.
• Windows GNU LD: "corrupt .drectve at end of def file" and "-exclude-symbols:'...' unrecognized". This indicates LD is older than binutils 2.40 and LLVM is 15 or newer (GNU linker warns “corrupt .drectve” on staticlib binary generated with Rust 1.70 on Windows #112368), which is common on the default GitHub Actions 2022 image. In practice it does not cause issues, so it should be silenced (as long as we are sure binutils is older than 2.40).
• wasm32-unknown-unknown LLD: "archive member '...' is neither Wasm object file nor LLVM bitcode". This is tracked by Official binaries for wasm32-unknown-unknown (and potentially other WASM platforms?) contain code for the wrong architecture #132802 and should be silenced until that issue is resolved.

Known Warnings (should not be silenced)

• powerpc64 GNU LD: "bss-plt forced due to '...'.o (PowerPC linker warning: bss-plt forced due to {name}.o #136131). This seems like a real issue?
• macOS ld: "cannot export hidden symbol compiler_builtins::'...'" (show linker output even if the linker succeeds #119286 (comment)). this seems like a real issue, and only appears when building compiler_builtins from source.
• macOS ld: "cannot export hidden symbol ___llvm_profile_filename" when building tests/ui/issues/issue-85461.rs (probably from -Cinstrument-coverage)
• x64 linux GNU ld: "relocation in read-only section `.rodata.global.c'" and "creating DT_TEXTREL in a shared object" when building rustc_codegen_gcc
• macOS ld: "search path 'target/debug/build/libz-sys-ae8c893dbe111c55/out/lib64' not found" (Make user-specified cflags take precedence over cc-rs flags cmake-rs#232 (comment), being fixed by Fix unnecessary search path warning on macOS libz-sys#235)
• macOS ld: "directory not found for option '-L...'" (Target modifiers (special marked options) are recorded in metainfo #133138 (comment))
• i686-uefi lld: "section name .debug_frame is longer than 8 characters" (show linker output even if the linker succeeds #119286 (comment), being fixed in Disable DWARF in linker options for i686-unknown-uefi #136791)

Unresolved Questions

• Is there any other noisy output we should silence?
• Can we find a way to do a crater run for non-linux platforms?

Implementation history

• Initial implementation: show linker output even if the linker succeeds #119286
• Report of it being too noisy: linker failure on macOS when building Miri: "linker stderr: ld: ignoring duplicate libraries" #136086
• Downgraded to allow by default: Downgrade linker-warnings to allow-by-default #136098

@rustbot label L-linker_messages T-compiler A-linkage E-medium E-help-wanted E-mentor

[ehuss]

Why should "built for newer 'macOS' version than being linked" be silenced? My instinct is that indicates libraries are being built with the wrong macos deployment target.

cc #136113

[ehuss]

windows-gnu generates a large amount of warnings. On a simple hello-world, it looks like:

warning: linker stderr: Warning: corrupt .drectve at end of def file␍
         Warning: .drectve `-exclude-symbols:"_ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h327fee2a44a3bd76E" ' unrecognized␍
         Warning: .drectve `-exclude-symbols:_ZN4core3ops8function6FnOnce9call_once17h4937986b238ad4e8E ' unrecognized␍
         Warning: corrupt .drectve at end of def file␍
         Warning: corrupt .drectve at end of def file␍
         Warning: .drectve `-exclude-symbols:_ZN3std2rt10lang_start17h03b3de1902cb95bfE ' unrecognized␍
         Warning: corrupt .drectve at end of def file␍
         Warning: corrupt .drectve at end of def file␍
         Warning: corrupt .drectve at end of def file␍
  |
  = note: `#[warn(linker_messages)]` on by default

Might be good to know why it does that.

[jyn514]

@ehuss what version of gnu ld do you have installed? that looks like #119286 (comment), which was fixed by updating the toolchain in #119229

[jyn514]

Why should "built for newer 'macOS' version than being linked" be silenced? My instinct is that indicates libraries are being built with the wrong macos deployment target.

i do not know much about macos linking. what can go wrong if you have mismatched deployment targets?

[kpreid]

wasm32-unknown-unknown cdylib builds are emitting warnings from compiler_builtins. More info in #136109.

warning: linker stderr: rust-lld: /Users/kpreid/.rustup/toolchains/nightly-2025-01-26-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcompiler_builtins-cef32f9876d137b7.rlib: archive member '45c91108d938afe8-absvdi2.o' is neither Wasm object file nor LLVM bitcode
         rust-lld: /Users/kpreid/.rustup/toolchains/nightly-2025-01-26-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcompiler_builtins-cef32f9876d137b7.rlib: archive member '45c91108d938afe8-absvsi2.o' is neither Wasm object file nor LLVM bitcode
         rust-lld: /Users/kpreid/.rustup/toolchains/nightly-2025-01-26-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcompiler_builtins-cef32f9876d137b7.rlib: archive member '45c91108d938afe8-absvti2.o' is neither Wasm object file nor LLVM bitcode
...

[ehuss]

@ehuss what version of gnu ld do you have installed? that looks like #119286 (comment), which was fixed by updating the toolchain in #119229

Looks like I had a relatively old version of ld on my system. However, the default GitHub Actions 2022 image seems to be affected. It looks like it has GNU Binutils 2.39. 2025 has binutils 2.42 which I think should work? Or maybe it can be upgraded with chocolatey?

[jyn514]

@ehuss cool, sounds like it’s the same root cause. given that it seems harmless in practice, i will change rustc to filter it out of the lint (i.e. put it in linker-info, not linker-messages).

@kpreid do you happen to know who maintains the wasm32-unknown target?