Thanks for the suggestion. The main reason for building this .so within the Wine build system is to have build-time validation and to avoid relying on the `LD_LIBRARY_PATH` hack, since in practice it relies on hidden linker APIs which are not part of the public contract, are unstable across Android releases, and may break unexpectedly. As mentioned in the PR, the goal here is to separate Wine from the JVM/activity process. This helps avoid both: * JVM-imposed restrictions (for example seccomp), * and ABI conflicts (like the register clobbering issue that required `wrap_java_call`). This is meant to avoid both existing and potential future issues in that area. Also, this is roughly the approach used by projects like Termux Wine setups, GameHub, GameNative, and Winlator, where Wine runs outside of the JVM context. That seems to be why they don't run into the same ABI and seccomp-related problems. Given that context, is there a recommended way to integrate such a .so into the build, or is packaging still considered the only acceptable approach? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10569#note_135147