You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I can understand, the winapi-i386/x86_64-pc-windows-gnu crates exist because the Rust MinGW toolchain does not include the import libraries for these DLLs, right? Therefore there should no way to link against them.
Finished dev [unoptimized + debuginfo] target(s) in 0.59 secs
Running `target\debug\test.exe`
Would it be possible for winapi-rs to drop those auxilliary crates and just add the C:\\Windows\\System32\ folder to the native search dirs for MinGW? It would greatly simplify development.
Note: the folders, on a 64-bit native Windows, are \System32 for 64-bit DLLs and \SysWOW64 for 32-bit DLLs.
The text was updated successfully, but these errors were encountered:
GabrielMajeri
changed the title
Link directly against DLLs with MinGW to eliminate the need for import libraries
Link directly against DLLs for gnu toolchains to eliminate the need for import libraries
Jul 12, 2017
No.
I'm well are of ld's claimed ability to link against dlls directly and it isn't something I can rely on.
Assuming that winapi is being built on Windows doesn't work, because people might want to cross compile to Windows from linux or Mac which obviously don't have the dlls.
Or what if the user is on an older Windows and trying to target a newer Windows, so their dlls don't have those newer functions?
Or how about linking against the api set dlls which don't even actually exist as files due to the way the windows loader works?
Providing import libraries is something that I can do and ensures linking will always work regardless of what the host system is.
As far as I can understand, the
winapi-i386/x86_64-pc-windows-gnu
crates exist because the Rust MinGW toolchain does not include the import libraries for these DLLs, right? Therefore there should no way to link against them.Except there is, and it requires no import libraries.
ld
is a really cool linker - it's able to link against DLLs without requiring an import.lib
file.Here is an example. Let's say I am trying to build this using the
nightly-gnu
toolchain on Windows:If I compile this as-is, I get a link error with the
ld
linker.But
AudioEng
is a DLL, and it exists in myC:\Windows\System32\
folder. If I askld
to also search in that folder, by using abuild.rs
file:I can now build it just fine:
Would it be possible for
winapi-rs
to drop those auxilliary crates and just add theC:\\Windows\\System32\
folder to the native search dirs for MinGW? It would greatly simplify development.Note: the folders, on a 64-bit native Windows, are
\System32
for 64-bit DLLs and\SysWOW64
for 32-bit DLLs.The text was updated successfully, but these errors were encountered: