Tracking Issue for enabling the linker-messages lint by default

@rustbot

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. split out linker-info from linker-messages #149937 (comment)
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. split out linker-info from linker-messages #149937 (comment)
Make linker-messages ignore -Dwarnings. linker-messages is warn-by-default again #153968
Make linker-messages warn by default again. linker-messages is warn-by-default again #153968

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

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)
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 have been fixed by Fix host code appearing in Wasm binaries #137457.

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
Split out from linker-info: split out linker-info from linker-messages #149937
Made warn-by-default and unaffected by -D warnings: linker-messages is warn-by-default again #153968
Fixed the implementation of raw-dylib on Linux: elf-raw-dylib: set type for functions #153090
Removed a linker-warning in a run-make test: don't use no_main and no_core to test IBT #149969
Removed clang warnings about -no-pie on Windows: Do no add -no-pie on Windows #152793
Fixed PLT warnings on PowerPC: Use +secure-plt for powerpc-unknown-linux-gnu{,spe} #136154
Fixed i686 UEFI warnings about unsupported DWARF: Disable DWARF in linker options for i686-unknown-uefi #136791
Fixed invalid object code on wasm32-unknown: Fix host code appearing in Wasm binaries #137457
Fixed symbol visibility in dylibs: Don't attempt to export compiler-builtins symbols from rust dylibs #137736

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

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

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.

@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

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?

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

@ehuss

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

@daxpedda

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

Rollup merge of rust-lang#149937 - jyn514:linker-info, r=mati865

Unrolled build for #149937

As discussed on zulip, this probably needs more discussion before -D warnings starts applying to it. I suggested that we might be able to change the force-warn infrastructure to still allow allowing/denying individual lints, but not to have them affected by -D warnings.

In the meantime, I'm going to add a note: force-warn that says that some of the linker output was hidden.

Auto merge of #153968 - jyn514:jyn/linker-warn-by-default, r=mati865

this merged in #153968 ! i'm going to leave the tracking issue open for a ~week just in case we end up reverting it again.

Auto merge of #153968 - jyn514:jyn/linker-warn-by-default, r=mati865

One week definitely has passed.

Navigation Menu

Repository navigation

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

About tracking issues

Steps

Known Warnings (should be silenced)

Known Warnings (should not be silenced)

Unresolved Questions

Implementation history

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for enabling the linker-messages lint by default #136096

Description

About tracking issues

Steps

Known Warnings (should be silenced)

Known Warnings (should not be silenced)

Unresolved Questions

Implementation history

Activity

ehuss commented on Jan 26, 2025

ehuss commented on Jan 26, 2025

jyn514 commented on Jan 26, 2025

jyn514 commented on Jan 26, 2025

kpreid commented on Jan 26, 2025

ehuss commented on Jan 27, 2025

jyn514 commented on Jan 27, 2025

kpreid commented on Jan 27, 2025

24 remaining items

jyn514 commented on Mar 20, 2026

jyn514 commented on May 2, 2026

mati865 commented on Jun 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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