Tracking Issue for enabling the linker-messages lint by default · Issue #136096 · rust-lang/rust (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Appearance settings

Description

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