WohlSoft / LuaJIT

Fork of LuaJIT repository which adds CMake build and a small change that forces usage of UTF8 (instead of ANSI) in file system paths on Windows
http://luajit.org
Other
40 stars 16 forks source link

Cannot cross-compile from Windows to Android using CMake #22

Closed mcclure closed 4 months ago

mcclure commented 1 year ago

Hello, I use your distribution of LuaJIT as part of the https://github.com/bjornbytes/lovr game development library, which includes your LuaJIT as a a CMake add_subdirectory. The CMake file in your distribution is extremely useful and works much better than the bodged one we used before. I have successfully used it to build on MacOS, build on Windows, and to cross-compile an Android version from a MacOS build machine.

Today I tried to use it to cross-compile an Android version from a Windows build machine. But it failed, and it failed because of a very small, fiddly configuration issue. The final lines of the build were:

C:\Users\Andi\work\g\lovr\deps\luajit\src\host\minilua.c(7617,1): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. [C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.vcxproj]
C:\Users\Andi\work\g\lovr\deps\luajit\src\host\minilua.c(7633,1): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. [C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.vcxproj]
  minilua.vcxproj -> C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\Debug\minilua.exe
  Building Custom Rule C:/Users/Andi/work/g/lovr/deps/luajit/src/host/cmake/minilua/CMakeLists.txt
[236/470] Generating buildvm_arch.h
FAILED: luajit/src/buildvm_arch.h C:/Users/Andi/work/g/lovr/build-apk/luajit/src/buildvm_arch.h
cmd.exe /C "cd /D C:\Users\Andi\work\g\lovr\build-apk\luajit\src && C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe C:/Users/Andi/work/g/lovr/deps/luajit/src/../dynasm/dynasm.lua -D FPU -D HFABI -D ENDIAN_LE -D P64 -D FFI -D JIT -D DUALNUM -D VER= -o C:/Users/Andi/work/g/lovr/build-apk/luajit/src/buildvm_arch.h C:/Users/Andi/work/g/lovr/deps/luajit/src/vm_arm64.dasc"
'C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe' is not recognized as an internal or external command,
operable program or batch file.
[241/470] Building CXX object glslang/SPIRV/CMakeFiles/SPIRV.dir/GlslangToSpv.cpp.o
ninja: build stopped: subcommand failed.

Looking carefully, what went wrong is clear: It builds the helper C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\Debug\minilua.exe. Then it attempts to execute C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe. Notice the Debug\ directory. The MSVC generator for cmake likes to put exes inside a Debug\ or Release\ subdirectory. However the .exe is then being invoked by (I think) the Ninja generator, which does not include that Debug/Release subdirectory when constructing the path it attempts to run minilua.exe from.

Is there some way to fix this?

Here is my command line build invocation, unfortunately in addition to being somewhat specific to my own machine it's a build invocation for lovr and not luajit directly:

set ANDROID_HOME=%LOCALAPPDATA%\Android\Sdk
set JAVA_HOME=C:\Users\Andi\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\221.6008.13.2211.9619390\jbr
set PATH=%PATH:C:\Program Files\CMake\bin;=%
set PATH=%ANDROID_HOME%\cmake\3.22.1\bin;%PATH%

cmake.exe ^
    -G Ninja ^
    -DANDROID=1 ^
    -DCMAKE_TOOLCHAIN_FILE=%ANDROID_HOME%\ndk\21.0.6113669\build\cmake\android.toolchain.cmake ^
    -DANDROID_SDK=%ANDROID_HOME% ^
    -DANDROID_ABI=arm64-v8a ^
    -DANDROID_NATIVE_API_LEVEL=23 ^
    -DANDROID_BUILD_TOOLS_VERSION=33.0.1 ^
    -DANDROID_KEYSTORE=C:\(REDACTED) ^
    -DANDROID_KEYSTORE_PASS=(REDACTED) ^
    -DANDROID_ASSETS=C:\Users\Andi\work\lv\lodr ^
    -DANDROID_PACKAGE=com.mermaid.test.skategirl_hotswap ^
    -DLOVR_APK_NAME=skategirl_hotswap ^
    -DUSE_PUREDATA=YES -DLOVR_ENABLE_PHYSICS=NO ^
    -DCMAKE_BUILD_TYPE=Release ^
    ..

This is building with WolhSoft LuaJIT 113eb1d172dfb6b

(Notice minilua is being build debug despite me having picked BUILD_TYPE Release, but this hardly matters.)

Wohlstand commented 1 year ago

There is the common and annoying case that happens on MSVC toolchains only which produces "Debug" and "Release" sub-directories to put executables into it, and this case confuses other part of code that expects their default placement. I could try to work around on this. You are lucky, because you wrote when I am on my computer right now, so, I'll make the workaround very soon.

mcclure commented 1 year ago

Thanks very much. By the way, letting the build fail, then running copy C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\Debug\minilua.exe C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe then running the build again, letting it fail on buildvm, then running copy C:\Users\Andi\work\g\lovr\build-apk\luajit\src\buildvm\Debug\buildvm.exe C:\Users\Andi\work\g\lovr\build-apk\luajit\src\buildvm\buildvm.exe then running the build again produces an apparently working LuaJIT. So I think I am at the moment unblocked. But obviously this is suboptimal and it would be good to fix it for the next person anyway.

Wohlstand commented 1 year ago

Just now I sent the thing, please try to build it from the scratch, will it work or not?

mcclure commented 1 year ago

Hello, thanks much. I pulled the luajit used for this build up to b4369853fcf2d2a9463 and recompiled with the same steps. Unfortunately it fails in the same place with what seems to be the same error.

C:\Users\Andi\work\g\lovr\deps\luajit\src\host\minilua.c(7633,1): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. [C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.vcxproj]
  minilua.vcxproj -> C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\Debug\minilua.exe
  Building Custom Rule C:/Users/Andi/work/g/lovr/deps/luajit/src/host/cmake/minilua/CMakeLists.txt
[208/457] Generating buildvm_arch.h
FAILED: luajit/src/buildvm_arch.h C:/Users/Andi/work/g/lovr/build-apk/luajit/src/buildvm_arch.h
cmd.exe /C "cd /D C:\Users\Andi\work\g\lovr\build-apk\luajit\src && C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe C:/Users/Andi/work/g/lovr/deps/luajit/src/../dynasm/dynasm.lua -D FPU -D HFABI -D ENDIAN_LE -D P64 -D FFI -D JIT -D DUALNUM -D VER= -o C:/Users/Andi/work/g/lovr/build-apk/luajit/src/buildvm_arch.h C:/Users/Andi/work/g/lovr/deps/luajit/src/vm_arm64.dasc"
'C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe' is not recognized as an internal or external command,
operable program or batch file.
[213/457] Building CXX object glslang/glslang/CMakeFiles/MachineIndependent.dir/MachineIndependent/linkValidate.cpp.o
ninja: build stopped: subcommand failed.
mcclure commented 1 year ago

Note: To be clear this was a clean build, I totally deleted the previous work tree.

mcclure commented 1 year ago

Looking at 5c4ccfa9c9f86f4
I am not sure I understand these changes, but:

Would this have effect on normal Windows builds? I think changing normal, non-Android-cross-compile Windows builds might not be a good idea. If the Debug/ is chopped off on normal (pure Windows) builds this might have unpredictable effects if two configurations are built from the same work tree.

It might be better to look for the exe in a different place if it somehow detects it's about to re-invoke a Windows build (I don't know if that's possible) rather than try to change where it's saved.

Thanks again though.

Wohlstand commented 1 year ago

Usually, the debug/release is defined by the CMAKE_BUILD_TYPE= variable, and these sub-directoreis aren't so useful, and they kills the cross-platform unification of the directory tree. And so, for debug and for release the separated build tree is required. And, this mess happens on MSVC toolchains only, on MinGW-based toolchains it works just fine.

Wohlstand commented 1 year ago

Anyway, could you show me the content of the "src/host/cmake/buildvm/" and "src/host/cmake/minilua/" inside the build directory?

mcclure commented 1 year ago

Contents of src/ after first failure (minilua.exe not found):

FILES.txt

Contents of src/ after manual copy of minilua.exe and second failure (buildvm.exe not found)

FILES2.txt

Contents of src/ after manual copy of buildvm.exe and successful build:

FILES3.txt

EDIT: This is with b4369853fcf2

Wohlstand commented 1 year ago

Damn... that means my workaround didn't worked. It's supposed it will force these executables being placed at the build-apk/luajit/src/minilua/, not at build-apk/luajit/src/minilua/Debug. изображение

I'll try something other soon.

mcclure commented 1 year ago

Yes, the exes were still in the Debug folder.

Wohlstand commented 1 year ago

Just now I made another workaround, it should work now. I'll try out the thing on another machine to ensure it works fine.

Wohlstand commented 1 year ago

Okay, locally at me, it puts binaries at the right place now, no longer into Debug/Release sub-directories.

bjornbytes commented 4 months ago

I just confirmed that this is working now in lovr.

Wohlstand commented 4 months ago

Then, I can close this. Thanks for the confirmation!