rustc: Link entire archives of native libraries #16110
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As discovered in rust-lang#15460, a particular #[link(kind = "static", ...)] line is not actually guaranteed to link the library at all. The reason for this is that if the external library doesn't have any referenced symbols in the object generated by rustc, the entire library is dropped by the linker. For dynamic native libraries, this is solved by passing -lfoo for all downstream compilations unconditionally. For static libraries in rlibs this is solved because the entire archive is bundled in the rlib. The only situation in which this was a problem was when a static native library was linked to a rust dynamic library. This commit brings the behavior of dylibs in line with rlibs by passing the --whole-archive flag to the linker when linking native libraries. On OSX, this uses the -force_load flag. This flag ensures that the entire archive is considered candidate for being linked into the final dynamic library. This is a breaking change because if any static library is included twice in the same compilation unit then the linker will start emitting errors about duplicate definitions now. The fix for this would involve only statically linking to a library once. Closes rust-lang#15460 [breaking-change]
bors
added a commit
that referenced
this pull request
Aug 4, 2014
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not actually guaranteed to link the library at all. The reason for this is that if the external library doesn't have any referenced symbols in the object generated by rustc, the entire library is dropped by the linker. For dynamic native libraries, this is solved by passing -lfoo for all downstream compilations unconditionally. For static libraries in rlibs this is solved because the entire archive is bundled in the rlib. The only situation in which this was a problem was when a static native library was linked to a rust dynamic library. This commit brings the behavior of dylibs in line with rlibs by passing the --whole-archive flag to the linker when linking native libraries. On OSX, this uses the -force_load flag. This flag ensures that the entire archive is considered candidate for being linked into the final dynamic library. This is a breaking change because if any static library is included twice in the same compilation unit then the linker will start emitting errors about duplicate definitions now. The fix for this would involve only statically linking to a library once. Closes #15460 [breaking-change]
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 3, 2024
Fixes rust-lang#16110. The way rust desugars doc comments when expanding macros is rendering it as raw strings delimited with hashes. Rust-analyzer wasn't aware of this, so the desugared doc comments wouldn't match correctly when on the LHS of macro declarations. This PR fixes this by porting the code used by rustc: https://github.com/rust-lang/rust/blob/4cfdbd328b7171b2328d11b950b1af0978d6b1ef/compiler/rustc_ast/src/tokenstream.rs#L6837
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 3, 2024
…-to-raw-string, r=Veykril fix(mbe): desugar doc correctly for mbe Fixes rust-lang#16110. The way rust desugars doc comments when expanding macros is rendering it as raw strings delimited with hashes. Rust-analyzer wasn't aware of this, so the desugared doc comments wouldn't match correctly when on the LHS of macro declarations. This PR fixes this by porting the code used by rustc: https://github.com/rust-lang/rust/blob/59096cdad0e527ce4d254b55aca58539f726d3d6/compiler/rustc_ast/src/tokenstream.rs#L662-L671
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not
actually guaranteed to link the library at all. The reason for this is that if
the external library doesn't have any referenced symbols in the object generated
by rustc, the entire library is dropped by the linker.
For dynamic native libraries, this is solved by passing -lfoo for all downstream
compilations unconditionally. For static libraries in rlibs this is solved
because the entire archive is bundled in the rlib. The only situation in which
this was a problem was when a static native library was linked to a rust dynamic
library.
This commit brings the behavior of dylibs in line with rlibs by passing the
--whole-archive flag to the linker when linking native libraries. On OSX, this
uses the -force_load flag. This flag ensures that the entire archive is
considered candidate for being linked into the final dynamic library.
This is a breaking change because if any static library is included twice in the
same compilation unit then the linker will start emitting errors about duplicate
definitions now. The fix for this would involve only statically linking to a
library once.
Closes #15460
[breaking-change]