search

veeenu / hudhook

A videogame overlay framework written in Rust, supporting DirectX and OpenGL
MIT License
209 stars 30 forks source link

Windows-GNU build target unsupported #117

Closed vars1ty closed 1 year ago

vars1ty commented 1 year ago

As mentioned briefly in #116, building with windows-gnu and injecting doesn't work. Although I know it's only really officially supported for Windows via MSVC, it would still be nice to have it working by cross-compiling from a different platform.

Steps:

  1. Install the x86_64-unknown-linux-gnu build target via rustup
  2. Create a simple DLL using for say, the OpenGL 3 hooks
  3. Build the DLL using cargo build --release --target x86_64-unknown-linux-gnu
  4. Inject it into a sample application/game with OpenGL using Cheat Engine
    • Cheat Engine because it gives more verbose error details than most other programs
  5. Watch it fail with an error where it fails to get something along the lines of "user profile directory", which isn't directly referenced anywhere in hudhook, but it is being triggered somewhere or by something else that's making it break

Using MSVC would obviously be the most ideal solution, not just because of this issue, but because of smaller build-sizes and other misc things. Although because it's a true hassle to get it even working on Linux, it doesn't want to compile hudhook nor anything other than some basic println Hello World applications.

Injecting a working DLL works just fine on Linux, so no issues there.

veeenu commented 1 year ago

A couple questions:

From the looks of it, it could either be something specific to CE, or something in the GNU runtime that expects something that isn't there. I have no experience with it so the best thing would be to attach with a debugger. I'll try to tinker with it soonish, but I'm a bit busy lately.

vars1ty commented 1 year ago

It's tied to GNU. I managed to work around the issue by using the MSVC toolchain on Linux via LLD. If anyone else is encountering the same issue, I wrote a guide for it here. Closing since I don't think there's much to do about it. The workaround works and working around this issue on the GNU toolchain will take weeks to solve.