-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
Use CMAKE_SYSTEM_PROCESSOR instead of CMAKE_HOST_SYSTEM_PROCESSOR #902
Conversation
The former is exactly the same as the latter if compiling natively, which is the output of `uname -m`. But this is the wrong architecture when cross compiling where we do not want the architecture we are compiling on (the build architecture in GNU terminology) but the architecture we are compiling for (the host architecture in GNU terminology). The CMAKE_SYSTEM_PROCESSOR variable is set to the correct host architecture value when cross compiling. With this change, it is possible to cross compile a arm64 executable of box64 on an amd64 machine. Without this change, the "install" target will be omitted, because CMakeLists.txt wrongly uses the build architecture to decide whether the install target should be added or not. Instead it should use the host architecture.
oh nice. I was patching cmakelists so I could cross comile install (used with checkinstall when building debs)
|
@josch this does not work what are your cross compilation commands? |
Hi, I see you are using https://github.com/Pi-Apps-Coders/box64-debs/blob/master/create-deb.sh to build this? I do not have time for a full review but that script does not look good. You seem to try and re-invent the wheel to do things other tools will do for you automatically. Using checkinstall is a bad way to create packages for Debian. It's meant for a quick-and-dirty solution but not appropriate for something that other people than yourself are supposed to use. Instead of trying to run everything manually, you can take advantage of existing tools like apt, dpkg and debhelper to do the whole process of installing build dependencies, cross-building the package, running the tests and creating the *.deb package for you. You then get the correct cmake command for free. I think the best way forward for you would be to either:
Here is the last successful cross-build log as proof that the packaging of box64 I did for Debian indeed works as expected: |
I am well aware of the alternative tools. I inherited the buildscripts from someone else. you are using debhelper which sets the this change helps when cross compiling with debhelper but should be documented. if you are using any other tool (or manually running the commands) you will have to pass the appropriate CMAKE_SYSTEM_PROCESSOR argument to cmake |
It is. For reference see the CMake documentation: https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PROCESSOR.html
It is. By the CMake docs.
Usually that is done as part of a toolchain file. But it is not the job of box64 to document how CMake works. |
sigh... read the docs again that you linked. I won't bother explaining it |
The former is exactly the same as the latter if compiling natively, which is the output of
uname -m
. But this is the wrong architecture when cross compiling where we do not want the architecture we are compiling on (the build architecture in GNU terminology) but the architecture we are compiling for (the host architecture in GNU terminology). The CMAKE_SYSTEM_PROCESSOR variable is set to the correct host architecture value when cross compiling.With this change, it is possible to cross compile a arm64 executable of box64 on an amd64 machine. Without this change, the "install" target will be omitted, because CMakeLists.txt wrongly uses the build architecture to decide whether the install target should be added or not. Instead it should use the host architecture.