Generate standalone libs so that projects can link without the Windows SDK #142
Comments
|
The same thing worked with winrt-rust, where |
|
Thanks Patrick, I'll probably do something similar and have winrt-rs generate its own lib for the handful of PAL functions that it needs. |
kennykerr
changed the title
|
@kennykerr Here's a pretty simple example of how you can generate include libs in the build script: https://github.com/Alovchin91/winrt-rs/commit/8cda7baa8f7c5c8e56eac20e31720062b5b8a518 build.rs: use std::env;
use std::process::Command;
fn main() {
if env::var("CARGO_CFG_WINDOWS").is_err() {
panic!("Only Windows operating system is supported.")
}
if "gnu" == &env::var("CARGO_CFG_TARGET_ENV").unwrap().to_lowercase() {
gen_coremessaging_lib();
}
}
fn gen_coremessaging_lib() {
let manifest_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
let lib_path = std::path::Path::new(&manifest_dir).join("lib");
let out_dir = env::var("OUT_DIR").unwrap();
let out_path = std::path::Path::new(&out_dir);
// build libcoremessaging.a
let status = Command::new("dlltool")
.arg("-d")
.arg(lib_path.join("CoreMessaging.def"))
.arg("-l")
.arg(out_path.join("libcoremessaging.a"))
.status()
.unwrap();
if !status.success() {
panic!("Failed to generate libcoremessaging.a")
}
println!("cargo:rustc-link-search=native={}", out_dir);
}CoreMessaging.def: This sample is for GNU toolchain (so MinGW can compile and run the tests), but I think for MSVC the idea is largely the same with the only difference being the use of I'm not so sure if it's worth a PR to fix the tests for GNU toolchain (since you need a LoadLibrary impl anyway) though. |
|
Thanks, I experimented with something like this here a while back, but it looks like it would require different code for each toolchain. |
|
Do you plan to support anything except Windows? If not, you should be good to go with 2 tools - It's part of mingw-w64 Homebrew package of course. |
|
The supposed fix in #166 didn't help: I'm still getting a linker error: (now |
|
Thanks @Boddlnagg - since I have no control over what libs you have on your build machine, this issue is still open and I'm still planning to solve the original issue which is to "Generate standalone libs so that projects can link without the Windows SDK". Until I get around to that, I believe the MSVC targets should work. |
|
Yes, the MSVC targets work, and it's not super urgent. I just happened to have set up CI testing for 32-bit GNU windows target in my project (because I wanted as much platform coverage as possible for my crossplatform library), otherwise I wouldn't even have noticed this. |
|
An alternative is to finally get |
|
I'd love it if we could leverage |
|
I think for now what I'll have to do is generate a tool that will build a |
|
I have pinned the following issue describing the problem as it is a common question: #463 |
In a prototype, I migrated from winrt-rust to winrt-rs in my MIDI library midir, see Boddlnagg/midir#56.
In the CI for that project, I also test building with the windows-gnu toolchain, and apparently it doesn't work with winrt-rs. I'm getting a linker error:
The requirement to link with
onecoreseems to come from https://github.com/microsoft/winrt-rs/blob/ed46a71f506c343b3eb4fa6c15a4d9db1397ebcf/src/runtime.rs#L15-L24.The text was updated successfully, but these errors were encountered: