Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mcclure opened this issue Mar 22, 2023 · 15 comments
Closed

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

mcclure opened this issue Mar 22, 2023 · 15 comments
Labels

Comments

@mcclure
Copy link

mcclure commented Mar 22, 2023

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.)

@Wohlstand
Copy link
Member

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
Copy link
Author

mcclure commented Mar 22, 2023

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 added a commit that referenced this issue Mar 22, 2023
@Wohlstand
Copy link
Member

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

@Wohlstand Wohlstand added the bug label Mar 22, 2023
@mcclure
Copy link
Author

mcclure commented Mar 22, 2023

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.

@mcclure
Copy link
Author

mcclure commented Mar 22, 2023

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

@mcclure
Copy link
Author

mcclure commented Mar 22, 2023

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.

@Wohlstand
Copy link
Member

Wohlstand commented Mar 22, 2023

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
Copy link
Member

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

@mcclure
Copy link
Author

mcclure commented Mar 23, 2023

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

@Wohlstand
Copy link
Member

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
Copy link
Author

mcclure commented Mar 23, 2023

Yes, the exes were still in the Debug folder.

@Wohlstand
Copy link
Member

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
Copy link
Member

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

@bjornbytes
Copy link

I just confirmed that this is working now in lovr.

@Wohlstand
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants