Handle LTO with an rlib/cdylib crate type#8254
Merged
bors merged 1 commit intorust-lang:masterfrom May 18, 2020
Merged
Conversation
|
r? @ehuss (rust_highfive has picked a reviewer for you, use r? to override) |
hellow554
reviewed
May 18, 2020
tests/testsuite/lto.rs
Outdated
There was a problem hiding this comment.
The release here isn't necessary. You could use profile.dev and omit the --release further down
Member
Author
There was a problem hiding this comment.
Ah that's ok, these are just internal tests.
ehuss
reviewed
May 18, 2020
src/cargo/core/compiler/lto.rs
Outdated
Contributor
There was a problem hiding this comment.
Should this also check for staticlib? I did a quick test, and trying to link a .a file generated with -Clinker-plugin-lto causes the linker to seg fault.
Member
Author
There was a problem hiding this comment.
Whoops yes indeed! I've tweaked this a bit to handle both in one go.
In the case that LTO is happening but we're also generating a cdylib/rlib simultatneously that means that the final artifact will use the rlib but the cdylib still needs to be produced. To get this to work the cdylib's dependency tree needs to be compiled with embedded bitcode. The cdylib itself will be linked with the linker because we can't LTO an rlib+cdylib compilation, but the final executable will need to load bitcode from all its deps. This is meant to address rust-lang/rust#72268
5fd347c to
b45fd8f
Compare
Contributor
|
👍 |
Contributor
|
📌 Commit b45fd8f has been approved by |
Contributor
Contributor
|
☀️ Test successful - checks-azure |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 20, 2020
Update cargo 9 commits in cb06cb2696df2567ce06d1a39b1b40612a29f853..500b2bd01c958f5a33b6aa3f080bea015877b83c 2020-05-08 21:57:44 +0000 to 2020-05-18 17:12:54 +0000 - Handle LTO with an rlib/cdylib crate type (rust-lang/cargo#8254) - Gracefully handle errors during a build. (rust-lang/cargo#8247) - Update `im-rc` to 15.0.0 (rust-lang/cargo#8255) - Fix `cargo update` with unused patch. (rust-lang/cargo#8243) - Rephrased error message for disallowed sections in virtual workspace (rust-lang/cargo#8200) - Ignore broken console output in some situations. (rust-lang/cargo#8236) - Expand error message to explain that a string was found (rust-lang/cargo#8235) - Add context to some fs errors. (rust-lang/cargo#8232) - Move SipHasher to an isolated module. (rust-lang/cargo#8233)
This file contains hidden or 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
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.
In the case that LTO is happening but we're also generating a
cdylib/rlib simultatneously that means that the final artifact will use
the rlib but the cdylib still needs to be produced. To get this to work
the cdylib's dependency tree needs to be compiled with embedded bitcode.
The cdylib itself will be linked with the linker because we can't LTO an
rlib+cdylib compilation, but the final executable will need to load
bitcode from all its deps.
This is meant to address rust-lang/rust#72268