Windows GCC Support: Ruby 3.1 windows linker error (missing x64-ucrt-ruby310.lib?) #160
Comments
|
+1 This is happening to me as well. I can't find any lib files to link to, so unsure how to solve this So what I did was, I renamed Edit 1: println!(r"cargo:rustc-link-search=D:\Ruby31-x64\bin");
println!(r"cargo:rustc-link-search=D:\Ruby31-x64\bin\ruby_builtin_dlls");
println!("cargo:rustc-link-lib=dylib=x64-ucrt-ruby310");Perhaps the problem is Rust or VC that's doing this. It refuses to link against the dynamic lib even though the search path and syntax seems right |
@Speak2Erase yes the Windows implementation is not thorough at all. I don't run the Windows OS other than an occasional VM so I put in enough effort to get a MVP out for Windows. I'd be glad to accept a PR to implement GCC support for the Windows OS from someone who develops natively in that OS. |
danielpclark
changed the title
|
@danielpclark Is it possible to dynamically link on Windows with msvc? Are there some steps that I missed? I followed the guide on the main page as much as I could, and everything seems fine (Ruby is shared and everything). The ruby conf function in the build script outputs all the right data too (I manually checked each one). Regardless of that however, no matter how much I try to do a dynamically linked build, it seems to fail. Support seems to be baked into the build script too. As afar as I can tell, Rust still errors out about static libs even when telling it to dynamically link and providing the right search path (leads me to believe it's a Rust error not a build script error, but I could be wrong) I'm happy to do testing or gather info if needed so this can get fixed asap as it's a pretty big blocker for anyone using the library |
I'll see if I can pull together a pull request. |
|
@cherryleafroad Dynamically linked builds are more supported across operating systems but statically linked works with some caveats. There are tests for both statically built and dynamically built. The windows build support was implemented 4 years ago ... looking into the CI logs it seems my focus was to get it to link properly and half of the implemented tests passed at the time. So it seems my MVP was "half of Rutie can run on Windows without issue". I didn't investigate as to whether the rest would work with a relatively easy fix or if they're multiple adjustments to be made. It's quite possible GCC will work much better as it works fully natively on Linux. Here's the last CI build I see that focussed on Windows support https://travis-ci.org/github/danielpclark/rutie/builds/445816834 I need to update the CI to point at Travis' new URL and I need to update the tests to reflect Ruby 3+. I plan to do that soon but I have a few big tasks around the house to get a big raised garden going first. |
@Speak2Erase thank you so much! |
|
I think I've had some progress, so I'd like to share. Ruby on Windows is mostly RubyInstaller2 which is the Gnu toolchain, Ruby: x64-mingw-ucrt
I'm not sure if the two formats were fully compatible. Next point, rb_cObject is a DLL's public data symbol. It needs to be treated as __declspec(dllimport) in C/C++.
I'm not sure how to dllimport the data symbol in Rust. I tried #[link(name="x64-ucrt-ruby310")]. src/rubysys/mod.rs
Without the #link direction: With the #link direction: FYR With the #link direction: |
|
Could you please try this? diff --git a/build.rs b/build.rs
index d4494cb..3308e12 100644
--- a/build.rs
+++ b/build.rs
@@ -207,7 +207,7 @@ fn ruby_lib_link_name() -> String {
fn dynamic_linker_args() {
let mut library = Library::new();
library.parse_libs_cflags(rbconfig("LIBRUBYARG_SHARED").as_bytes(), false);
- println!("cargo:rustc-link-lib=dylib={}", ruby_lib_link_name());
+ println!("cargo:rustc-link-lib=dylib=dylib:{}", ruby_lib_link_name());
library.parse_libs_cflags(rbconfig("LIBS").as_bytes(), false);
}
diff --git a/src/rubysys/mod.rs b/src/rubysys/mod.rs
index baee579..14072a2 100644
--- a/src/rubysys/mod.rs
+++ b/src/rubysys/mod.rs
@@ -19,6 +19,7 @@ pub mod vm;
use rubysys::types::Value;
+#[link(name="dylib")]
extern "C" {
pub static rb_cObject: Value;
} |
|
I'll make an effort to give this a try soon. |
|
Chipping in on this, I have tried @golirev 's fix and the following procedure works (for me):
cargo build --release ✔️ It's a not a solution that I'm very comfortable with though ... |
|
I was able to get "x64-ucrt-ruby320.lib" by excluding ".weak." from exports.def. However, when executing "cargo build --release" at $RUTIE_ROOT\example\rutie_ruby_example, but is generated as Because the example's dependency library is set to "..\.." [dependencies]
rutie = { path = "../../" } So, you'll need a build.rs for the example to specify the x64-ucrt-ruby320.lib. #[cfg(target_env = "msvc")]
use {
std::path::Path,
std::env,
};
fn main() {
// If windows OS do windows stuff
windows_support();
}
#[cfg(target_env = "msvc")]
fn windows_support() {
let deps_dir = Path::new("../../target").join(env::var_os("PROFILE").unwrap()).join("deps");
#[cfg(target_env = "msvc")]
println!("cargo:rustc-link-search={}", deps_dir.to_string_lossy());
}
#[cfg(not(target_env = "msvc"))]
fn windows_support() {}I haven't found a way to get the .lib output directory in a more general way. The simplest solution is to put the generated x64-ucrt-ruby320.lib in the same directory as below. eg. C:\rubyinstaller-3.2.0-1-x64\lib\x64-ucrt-ruby320.lib ... I use 7-ZIP archive version. |
It looks like rutie tries to link against
x64-ucrt-ruby310.lib, which as far as I am aware, is nonexistent, at least in ruby builds from rubyinstaller and a fresh build off of git with msys2.Forgive me if I'm mistaken, but I believe
.libfiles are produced when compiling something with MSVC, not GCC from msys2.I went ahead and compiled ruby using msys2 straight from git, and couldn't find any
.libfiles anywhere.I also checked an old MSVC ruby build I have on hand, and it did spit out a handful of
.libfiles.It looks like rutie is linking against the wrong Ruby library on Windows, and should instead be linking against something else.
The text was updated successfully, but these errors were encountered: