Uh oh!
There was an error while loading. Please reload this page.
Create _imp__ symbols also when doing ThinLTO - #129079
Conversation
rustbot
commented
Aug 14, 2024
rustbot has assigned @compiler-errors. Use |
wesleywiser
left a comment
There was a problem hiding this comment.
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.
Zoxc
commented
Aug 20, 2024
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
562c0d1CompareChrisDenton
commented
Sep 22, 2024
Note that merged this fixes #111480 |
wesleywiser
left a comment
There was a problem hiding this comment.
Talked with @lqd offline about his comment and I'm fine with merging this as-is.
wesleywiser
commented
Oct 11, 2024
bors
commented
Oct 11, 2024
lqd
commented
Oct 11, 2024
@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? |
ChrisDenton
commented
Oct 11, 2024
lqd
commented
Oct 11, 2024
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. |
ChrisDenton
commented
Oct 11, 2024
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#129079Fixesrust-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#129079Fixesrust-lang#127890
Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed. try-job: i686-mingw-1 try-job: i686-mingw-2 try-job: i686-mingw-3 try-job: x86_64-mingw-1 try-job: x86_64-mingw-2 try-job: dist-i686-mingw try-job: dist-x86_64-mingw
Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed. try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: i686-msvc-1 try-job: i686-msvc-2 try-job: x86_64-msvc-ext1 try-job: x86_64-msvc-ext2 try-job: x86_64-msvc-ext3 try-job: dist-x86_64-msvc try-job: dist-i686-msvc try-job: dist-aarch64-msvc
…Denton Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed.
…Denton Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed.
…Denton Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed.
…nton Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed.
…nton Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed.
…nton Remove obsolete Windows ThinLTO+TLS workaround The bug rust-lang#109797 has been fixed by rust-lang#129079, so this workaround is no longer needed.
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'slinkcan fix these up (and emits warnings), butlldseems to currently be unable to.This PR also does this generation for ThinLTO avoiding those issues with
lldand also avoids the warnings onlink.This is an workaround for #81408.
cc @lqd