steamworks-rs
steamworks-rs copied to clipboard
cargo run doesn't work
Hello @Noxime!
I was able to build steamworks-rs
in macOS 10.15.7 and Windows 10, but when I try to run with cargo run
I get an error message, in both systems:
Windows:
cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Running `target\debug\hello_world.exe`
error: process didn't exit successfully: `target\debug\hello_world.exe` (exit code: 0xc0000135, STATUS_DLL_NOT_FOUND)
macOS
cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running `target/debug/hello_world`
dyld: Library not loaded: @loader_path/libsteam_api.dylib
Referenced from: /Users/pedroivo/Desktop/hello_world/target/debug/hello_world
Reason: image not found
I've tried multiple things, from setting $PATH to creating new profile files, but can't make it work in either systems. Thoughts on what should I try to make it work?
Thank you!
Hello @Noxime!
Did some testing, but now using a different Windows computer, with a fresh start and clean install, but got the exact same error message. I also ran Dependency Walker, that pointed the same error: can't find the DLL files to run the build.
And I noticed the files are already inside target/debug/build/steamworks-sys-21a7aa5b158c52ad/out
, but I'm guessing when it's being built, it's not binding to the appropriate target folder.
Any clues on why this is happening? Can't seem to find anything related to that... Thank you!
Yeah, I get the exact same problem, only on Linux so it can't find the .so file
Sorry to necro an old issue and I hope you have already fixed it. This issue is because steamworks is a dynamic library so needs to be loaded at runtime rather than statically linked like most things in Rust. This means you need the .so/.dll/.dylib in your loader path, usually next to your binary. I dont think we can do this automatically from a build script, as they are only allowed to write to the /out directory. Maybe a section in the readme would clear up this issue for users
Hey @Noxime. Thanks for having the time! 😄 I decided to go with a different approach, because I wasn't able to fully understand what to do here... So yeah, maybe a more detailed documentation would be good for users like me! (:
Yeah, I get the exact same problem, only on Linux so it can't find the .so file
I fixed it on linux with this on build.rs
:
#[cfg(target_os="linux")]
println!("cargo:rustc-link-arg=-Wl,-rpath,$ORIGIN");
that way it will look for the .so
file on the same directory of the executable
I added a snippet at the end of the README in #03d2816. What are some of our options when it comes to improving this, or is just better documentation the way to go?