-
Notifications
You must be signed in to change notification settings - Fork 497
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
Linker error calling certain functions #463
Comments
The second workaround seems easier but unfortunately I do not see how to it. Could you provide some guidance? |
Hang in there - I'm adding a workaround that should fix this up while we wait for the eventual solution. |
I applied a workaround - do let me know if that help. #465 |
I ran into linker issues when trying to use the HasExpandedResources API. Here's my code:
Linker says:
The docs for this function say to link against WindowsApp.lib though, so not sure why that API set ends up here... |
Thanks for the repro - I'll update the workaround to cover this. |
A more comprehensive workaround is now in place to deal with the linker issue. You should now be able to use this function without issue. |
It does build now, thank you! |
It doesn't run though. Program tries to load a DLL with the wrong name and crashes. |
Can you elaborate? I added a test for the function you mentioned. It does load and run successfully. windows-rs/crates/tests/tests/win32.rs Lines 275 to 284 in 50d9aa4
|
You can use |
Here the
As you see it is linked against I am running Win7 on this development machine. But it does have Visual Studio 2019 and tools. Would that explain it? If so will that be the same the future (keep relying on this "proxy" libs/dlls) or is it only temporary due to the workaround and will bind against native libs when the project matures? |
Ah, so that would work on Windows 10. The loader figures out how to redirect the call from the api set DLL to the actual DLL. We don't support Windows 7 and I encourage you to upgrade. I have however requested the metadata refer to the actual DLLs rather than the API set DLLs to make the metadata more compatible with older versions of Windows. That combined with DLL imports mentioned above and this should just work on older versions of Windows. |
Thank you! Is there a way I could edit the metadata used for my project manually in the meantime? |
You can create your own .winmd with the definitions you need, a unique namespace with a single definition of Part of #81 is allowing you to define metadata directly in Rust. At that point you'd also be able to define the But probably the simplest solution is to plead with @sotteson1 to make sure |
I'm having a similar issue LINK failure with calling functions in the following namespace windows::win32::net_management::*. Specifically, NetGroupEnum (and Ilk) Not sure if your fix can address this; but the failures occur when trying to resolving samcli.lib and wkscli.lib. |
Something in: windows::win32::windows_programming::* Causes (I know that using * is not probably advised, but it's currently only way to get some sort of autocompletion working.) |
Here's the PR to ultimately solve this issue in the Rust compiler: rust-lang/rust#84171 |
To clarify, that's the first of several PRs that will be necessary to solve this problem for the general case. The umbrella issue (rust-lang/rust#58713) is probably a better place to track the progress of this work. |
Just a note: (which probably doesn't matter a lot) but adding |
The metadata indicates the name of the DLL that exports the given function, but Rust doesn't yet support DLL imports and expects a LIB file to resolve those imports. If you have the Windows SDK installed, there will usually be a LIB file by the right name that Rust can use but this is not guaranteed. There are a few edge cases where this doesn't quite line up. I considered generating my own LIB files for the
windows
crate but we have some folks looking into implementing DLL imports for Rust and I'm hopeful that will arrive soon.One workaround is to generate and provide your own lib files. This process is briefly described here.
Another workaround is to copy the declaration just for the function in question and change the name of the lib to match a suitable lib that does support the function. The msdn docs usually have the correct name of a lib.
The text was updated successfully, but these errors were encountered: