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.
• i686-uefi lld: "section name .debug_frame is longer than 8 characters" (show linker output even if the linker succeeds #119286 (comment)). @nicholasbishop has volunteered to investigate this (nicholas, have you filed an issue upstream yet?)

Known Warnings (should not be silenced)

• powerpc64 GNU LD: "bss-plt forced due to '...'.o (Tracking Issue for enabling the linker-messages lint by default #136096 (comment)). 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
• 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))
• macOS ld: "directory not found for option '-L...'" (Target modifiers (special marked options) are recorded in metainfo #133138 (comment))

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

[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?

[kpreid]

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

I am not in the loop here, but I believe the answer is “nobody”. Quote from Jubilee on Zulip in 2023:

I think wasm32-unknown-unknown predates the current policy re: requiring enrolled target maintainers and thus has none to which that task is formally delegated. Or at least no one's been written down.

Perhaps @daxpedda could help out here; they at least work on wasm-bindgen and so have a reason to care about wasm toolchain behaviors.

[ehuss]

alexcrichton is the target maintainer for wasm32-unknown-unknown.

I believe the issue with compiler_builtins is a known thing where it includes object code. This was recently discussed in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Building.20wasm32v1-none.20target.20fails/near/492830795 (see also #132802).

[Zalathar]

I noticed today that a bunch of ui tests were failing locally on a clean branch, on my macOS system:

warning: linker stderr: ld: object file (/Users/stuart/Dev/rust/rust/build/aarch64-apple-darwin/native/rust-test-helpers/librust_test_helpers.a[2](3bc902bd874a8351-rust_test_helpers.o)) was built for newer 'macOS' version (14.4) than being linked (11.0)
   |
   = note: `#[warn(linker_messages)]` on by default

warning: 1 warning emitted

The key part being:

was built for newer 'macOS' version (14.4) than being linked (11.0)

Not an immediate concern due to the impending lint level downgrade (#136098), but something to keep in mind when trying to turn this on again.

[tgross35]

libc is getting a couple of interesting ones. On aarch64-apple-darwin:

error: linker stderr: ld: ignoring duplicate libraries: '-lc', '-lm'

On powerpc-unknown-linux-gnu (edit: this will be fixed by #136154):

 warning: linker stderr: /usr/lib/gcc-cross/powerpc-linux-gnu/13/../../../../powerpc-linux-gnu/bin/ld: bss-plt forced due to /checkout/target/powerpc-unknown-linux-gnu/debug/deps/const_fn-5906628da0f5d31e.2bjw3mlsf69tu9e94ehzuvs4u.rcgu.o

And then windows-gnu has the already-mentioned Warning: corrupt .drectve at end of def file␍. The Apple issue can probably be fixed in libc (assuming those just get passed by default so we just don't need to specify the link(name = ...)) and the Windows issue is known, but I am not sure where the ppc issue is coming from.

Relevant CI run: rust-lang/libc#4254.