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

Most upvoted comments

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.

Something in:

windows::win32::windows_programming::*

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 as windows-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.