-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Mark functions created for raw-dylib
on x86 with DllImport storage class
#104511
Conversation
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
Thanks, @dpaoliello! Looks good to me. @mati865, you added that "backwards compatibility" comment in #72049 -- do you think it is still up to date? I can't quite tell if that PR added a regression test for the issue this refers to or not. |
@michaelwoerister I cannot test it any time soon but I think thanks to that one can create DLL that "exports" symbols without dllexport (so only bare |
Thanks for the info, @mati865! It sounds like we are generally lacking test coverage for windows-gnu here. It's sad that we are relying so much on heuristics when it comes to |
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.
Thanks for the quick fix, @dpaoliello!
I think we can merge it with a little more documentation (see below).
6b17af0
to
67e746c
Compare
Thanks, @dpaoliello! @bors r+ |
…, r=michaelwoerister Mark functions created for `raw-dylib` on x86 with DllImport storage class Fix for rust-lang#104453 ## Issue Details On x86 Windows, LLVM uses 'L' as the prefix for any private global symbols (`PrivateGlobalPrefix`), so when the `raw-dylib` feature creates an undecorated function symbol that begins with an 'L' LLVM misinterprets that as a private global symbol that it created and so fails the compilation at a later stage since such a symbol must have a definition. ## Fix Details Mark the function we are creating for `raw-dylib` with `DllImport` storage class (this was already being done for MSVC at a later point for `callee::get_fn` but not for GNU (due to "backwards compatibility")): this will cause LLVM to prefix the name with `__imp_` and so it won't mistake it for a private global symbol.
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#104420 (Fix doc example for `wrapping_abs`) - rust-lang#104499 (rustdoc JSON: Use `Function` everywhere and remove `Method`) - rust-lang#104500 (`rustc_ast`: remove `ref` patterns) - rust-lang#104511 (Mark functions created for `raw-dylib` on x86 with DllImport storage class) - rust-lang#104595 (Add `PolyExistentialPredicate` type alias) - rust-lang#104605 (deduplicate constant evaluation in cranelift backend) - rust-lang#104628 (Revert "Update CI to use Android NDK r25b") - rust-lang#104662 (Streamline deriving on packed structs.) - rust-lang#104667 (Revert formatting changes of a test) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fix for #104453
Issue Details
On x86 Windows, LLVM uses 'L' as the prefix for any private global symbols (
PrivateGlobalPrefix
), so when theraw-dylib
feature creates an undecorated function symbol that begins with an 'L' LLVM misinterprets that as a private global symbol that it created and so fails the compilation at a later stage since such a symbol must have a definition.Fix Details
Mark the function we are creating for
raw-dylib
withDllImport
storage class (this was already being done for MSVC at a later point forcallee::get_fn
but not for GNU (due to "backwards compatibility")): this will cause LLVM to prefix the name with__imp_
and so it won't mistake it for a private global symbol.