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

Home Page:http://luajit.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot cross-compile from Windows to Android using CMake

mcclure opened this issue · comments

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 113eb1d

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

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.

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.

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

Hello, thanks much. I pulled the luajit used for this build up to b436985 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.

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

Looking at 5c4ccfa
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.

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.

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

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 b436985

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.

Yes, the exes were still in the Debug folder.

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

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

I just confirmed that this is working now in lovr.

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