Rust linker seeks a LIB, rather than a DLL
Asked Answered
T

1

6

I'm experimenting with Rust on Windows. My code declares and calls a function in an external library.

The declaration is like this:

#[link(name = "Rvea0326nc-64")]
extern "C" {
  fn WeibullSpeedProbability(wa: &f32, wk: &f32, qu: &f32, prob: &f32, theerr: &i32) -> ();
}

(It's all ByRef because the DLL is Fortran. It's built with the Intel compiler.)

Note that the file name has no extension. The DLL is in the \target\debug\deps folder of the Rust project.

According to the documentation here https://doc.rust-lang.org/std/keyword.extern.html, this should import a DLL on Windows, but I get an error, thus:

error: linking with `link.exe` failed: exit code: 1181 
<SNIP>
= note: LINK : fatal error LNK1181: cannot open input file 'Rvea0326nc-64.lib'

Sure enough, if I find and copy in the *.lib file from which the DLL was generated, everything works fine. The DLL is apparently irrelevant.

I have tried explicitly adding ".dll" to the link name, but Rust just complains that it cannot find Rvea0326nc-64.dll.lib.

Is the documentation wrong? Have I missed something? Is there a way to get Rust to work with the DLL?

Update: I found that when running the Rust-compiled executable directly, the DLL is required and the LIB is not.

Terylene answered 13/8, 2020 at 11:22 Comment(0)
R
3

Without having too much experience with FFI in Rust, I can imagine to compile your program, you will need the .lib installed on your machine, so that rustc can correctly check that the FFI function is correct. Then when the produced binary is run, it loads the .dll at runtime and uses it.

Try to see if after producing a binary with the .lib installed, that you can run that binary without the .lib installed.

Revolutionary answered 13/8, 2020 at 11:42 Comment(2)
Thanks. Your intuition is exactly correct. The Lib is needed at compile time, but the DLL is needed at runtime. C++ is like this too, so I should have worked it out. Mostly I work with other client languages that compile happily against the DLL itself (but then fail at runtime if you've made a mistake in the import declaration).Terylene
I think we need a switch/method to force the compiler to accept a *.dll only environment. I have a *.dll where we do not export the *.lib file, so the only way I could build this is with an internal build. Our customers do not recieve *.lib files, only *.dll files and would be unable to link to these API's unless I can create dummy *.lib objects perhaps with bindgen. (Need to research.. I'm a newbie) I expect bindgen is how this is done.Puleo

© 2022 - 2024 — McMap. All rights reserved.