Add optional support for raw-dylib
#2164
Conversation
|
In addition to waiting on stabilization, testing uncovered an issue blocking support on And cross compilation is also missing: |
|
Thanks for doing this! Looking forward to taking it for a spin shortly! |
|
You're welcome! This certainly makes it easier to kick the tires with |
| macro_rules! link { | ||
| ($library:literal $abi:literal $(#[$($doc:tt)*])* fn $name:ident($($arg:ident: $argty:ty),*)->$ret:ty) => ( | ||
| #[link(name = $library, kind = "raw-dylib", modifiers = "+verbatim")] | ||
| extern "system" { |
There was a problem hiding this comment.
Is there a specific reason this was made to ignore $abi? (it's now "C" rather than "system", as a workaround for variadic functions).
There was a problem hiding this comment.
Yes, it's a workaround for this: rust-lang/rust#110505
There was a problem hiding this comment.
Yes, that's why it's C now, but why was it "system" rather than $abi?
There was a problem hiding this comment.
Because the ABI is generally only relevant for x86 and "system" should work for all ARM64 and x64 Windows APIs.
Following on from #2149, this update adds optional support for
raw-dylibin thewindowsandwindows-syscrates. This is currently only supported on nightly but is on track for stabilization. Thelinkmacro is "overloaded" to adjust the way the Rustlinkattribute is configured depending on whether thewindows_raw_dylibflag is specified.The
linkmacro will generate the traditional form if thewindows_raw_dylibflag is not specified. In that mode, it continues to rely on the target libs provided by thewindows-targetscrate. However, thewindows_raw_dylibflag ensures that no libs are needed or downloaded. The name of the DLL is then used to instruct the Rust compiler to inject the appropriate import table entry directly and without the use of an import lib.I'll probably switch the
windowscrate over toraw-dylibunconditionally once the feature is stabilized but keep thewindows-syscrate optional to retain support for an older MSRV.