search

rdbo / libmem

Advanced Game Hacking Library for C, Modern C++, Rust and Python (Windows/Linux/FreeBSD) (Process/Memory Hacking) (Hooking/Detouring) (Cross Platform) (x86/x64) (DLL/SO Injection) (Internal/External) (Assembler/Disassembler)
GNU Affero General Public License v3.0
830 stars 101 forks source link

fix: target_os not respected on cross-compilation #224

Closed MeguminSama closed 6 months ago

MeguminSama commented 6 months ago

There seems to be a problem (maybe a cargo/rust bug) where the cfg macro's target_os is incorrect when doing cross-compilation (e.g. compiling for windows on Linux with xwin).

This causes a compilation on linux, targeting windows, to download the linux binaries, instead of the windows binaries.

This can be fixed by switching to reading the CARGO_CFG_TARGET_OS environment variable instead.

I found the fix for this from https://github.com/frida/frida-rust/pull/96 and have tested it on my end to success.

MeguminSama commented 6 months ago

actually it looks like these in bindings/rust/libmem-sys/build.rs are also affected. Not sure if using the cargo env vars for these will cause issues on your end with fetching the pre-compiled releases? Unlikely, but still possible.

let os_name = env::consts::OS;
let arch = env::consts::ARCH;

Replacing with:

let os_name = env::var("CARGO_CFG_TARGET_OS");
let arch = env::var("CARGO_CFG_TARGET_ARCH");

edit: will push to test it.

MeguminSama commented 6 months ago

Works on Windows(x86_64-msvc)

Cross Comp: Works on Linux(x86_64-gnu)->Windows(x86_64-msvc) Works on Linux(aarch64-musl)->Windows(x86_64-msvc)

I don't have easy access to other platforms to test on, but it seems to have the correct behaviour :)

rdbo commented 6 months ago

I was unaware of this issue, good to know Thank you!