windows-rs: Linker error calling certain functions
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.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19
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.
Something in:
Causes
fatal error LNK1181: cannot open input file 'APPHELP.lib'
.(I know that using * is not probably advised, but it’s currently only way to get some sort of autocompletion working.)
You can create your own .winmd with the definitions you need, a unique namespace with a single definition of
MiniDumpWriteDump
with a different DLL name to match the LIB name that will link to the original DLL. That would work as far aswindows-rs
is concerned, but creating it is a little complicated.Part of #81 is allowing you to define metadata directly in Rust. At that point you’d also be able to define the
MiniDumpWriteDump
function directly in Rust without the need for metadata, but that may be a while.But probably the simplest solution is to plead with @sotteson1 to make sure
MiniDumpWriteDump
is included in the fix for https://github.com/microsoft/win32metadata/issues/92. 😉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.
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.