-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create _imp__
symbols also when doing ThinLTO
#129079
Conversation
rustbot has assigned @compiler-errors. Use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a simple test case to demonstrate that the _imp__
symbols are generated now? Asm or llvm-ir test would be sufficient if it's too complex to do an end-to-end test.
I think we'd need to inspect the symbols in the linker inputs to test this. |
@wesleywiser what would you want to see in an end-to-end test? #81408 will pass before and after this PR, until we revert #103353 -- is lqd@f9fb8e9 what you have in mind? (note it doesn't duplicate cargo's use of |
713a006
to
562c0d1
Compare
Note that merged this fixes #111480 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Talked with @lqd offline about his comment and I'm fine with merging this as-is.
@ChrisDenton as you've done the most investigation on #111480, do we need a test for that issue, or is the one added in this PR good for it as well? That is, it seems like #111480 is a duplicate of #81408? |
IIRC there are a few issues when multiple crate types are used with cargo including cdylibs, and LTO enabled, like rust-lang/cargo#9672; other issues happen with PGO as well #117220 (I hope these issues don't emulate I guess we can leave #111480 as E-needs-test and people can use this one as a base and also test a cdylib in there if they want. The missing _imp symbols should be the root cause in both types of libraries anyways. |
Yeah I don't feel strongly either way. I'm happy with the test here as it does exercise the underlying problem. |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#129079 (Create `_imp__` symbols also when doing ThinLTO) - rust-lang#131208 (ABI: Pass aggregates by value on AIX) - rust-lang#131394 (fix(rustdoc): add space between struct fields and their descriptions) - rust-lang#131519 (Use Default visibility for rustc-generated C symbol declarations) - rust-lang#131541 (compiletest: Extract auxiliary-crate properties to their own module/struct) - rust-lang#131542 (next-solver: remove outdated FIXMEs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#129079 - Zoxc:thinlto_imp_symbols, r=wesleywiser Create `_imp__` symbols also when doing ThinLTO When generating a rlib crate on Windows we create `dllimport` / `_imp__` symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's `link` can fix these up (and emits warnings), but `lld` seems to currently be unable to. This PR also does this generation for ThinLTO avoiding those issues with `lld` and also avoids the warnings on `link`. This is an workaround for rust-lang#81408. cc `@lqd`
unpin and update memchr I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI. Possibly fixed by rust-lang#129079 try-job: x86_64-mingw try-job: i686-mingw
unpin and update memchr I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI. Possibly fixed by rust-lang#129079 Fixes rust-lang#127890
unpin and update memchr I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI. Possibly fixed by rust-lang/rust#129079 Fixes #127890
unpin and update memchr I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI. Possibly fixed by rust-lang#129079 Fixes rust-lang#127890
When generating a rlib crate on Windows we create
dllimport
/_imp__
symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft'slink
can fix these up (and emits warnings), butlld
seems to currently be unable to.This PR also does this generation for ThinLTO avoiding those issues with
lld
and also avoids the warnings onlink
.This is an workaround for #81408.
cc @lqd