DescentDevelopers
Enable building 32-bit binaries on 64-bit Linux via toolchain file
Works with variables passed on the commandline via -D CMAKE_.., flags from https://wiki.debian.org/Multiarch/Compiling
~~Avoids adding a toolchain file.~~ - It does not avoid this at all!
Can we do this in a different way? Not sure we need to start adding hacks, there has to be a proper way of doing it...
there has to be a proper way of doing it...
That was my thought as well. However the Debian one is adapted from modules shipped with cmake, which set lib specific paths in a similar way. The rpm/Fedora one though...
When setting these values from the outside (with -D directly or via CMakePresets.json) they will be overwritten and so the binaries are linked against the wrong 64 bit shared objects. Open to suggestions, any idea on that @bryanperris @DanielGibson @Lgt2x ?
I would argue that this is a small hack which will be removed later. For now it helps with tracking down 32/64 bit incompatibilities.
I very much prefer the toolchain approach! Could you update README instruction about how to use the 32bit toolchain (install i386 packages, and -DCMAKE_TOOLCHAIN_FILE=...
Thanks @winterheart for the Gentoo cmake toolchain file hint.
I will update the README in a separate PR.
I think linux 32bit clang is redundant. We added clang to matrix for some sanity checks and asan features in future. Most users can use gcc build.
Yes, can I exclude clang from the artifacs with an if: ${{ .. }} clause?
But for building, clang still has different warnings and might catch something in 32bit if we ever get to activating -Wall -Wextra -Werror. Oh and gcc has asan etc. as well.
@th1000s some conflicts in the workflow file need to be resolved now that unittests have been merged, but it seems good otherwise!
I'm getting an error when trying this branch.
I'm using Debian and have the following packages installed.
- gcc-13
- gcc-13-base
- gcc-13-cross-base
- gcc-13-i686-linux-gnu
- gcc-13-i686-linux-gnu-base
- gcc-13-x86-64-linux-gnu
- libgcc-13-dev
- libgcc-13-dev-i386-cross
- libgcc-s1
- libgcc-s1-i386-cross
Here's the error:
~/project/Descent3$ cmake --preset linux-32
Preset CMake variables:
CMAKE_TOOLCHAIN_FILE="tools/toolchain-32-bit.cmake"
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - broken
CMake Error at /usr/share/cmake-3.28/Modules/CMakeTestCCompiler.cmake:67 (message):
The C compiler
"/usr/bin/cc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: '/home/gravis/project/Descent3/builds/linux-32/CMakeFiles/CMakeScratch/TryCompile-cERwr8'
Run Build Command(s): /usr/bin/ninja -v cmTC_e4722
[1/2] /usr/bin/cc -DCMAKE_INTDIR=\"Debug\" -m32 -g -o CMakeFiles/cmTC_e4722.dir/Debug/testCCompiler.c.o -c /home/gravis/project/Descent3/builds/linux-32/CMakeFiles/CMakeScratch/TryCompile-cERwr8/testCCompiler.c
[2/2] : && /usr/bin/cc -m32 -g -m32 CMakeFiles/cmTC_e4722.dir/Debug/testCCompiler.c.o -o Debug/cmTC_e4722 && :
FAILED: Debug/cmTC_e4722
: && /usr/bin/cc -m32 -g -m32 CMakeFiles/cmTC_e4722.dir/Debug/testCCompiler.c.o -o Debug/cmTC_e4722 && :
/usr/bin/ld: cannot find Scrt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc: No such file or directory
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:8 (project)
-- Configuring incomplete, errors occurred!
g++-12-multilib is missing, see the updated README in the linked PR #226. Also, is gcc-13 from backports or sid?
Now that Icculus' 64-bit changes have been merged (#233), do we still need a 32 bit build ?
Now that Icculus' 64-bit changes have been merged (#233), do we still need a 32 bit build ?
Of course. "64-bit safe" merely means the behavior is the same regardless of what it's built for.
Now that Icculus' 64-bit changes have been merged (#233), do we still need a 32 bit build ?
Of course. "64-bit safe" merely means the behavior is the same regardless of what it's built for.
No it's not obvious. The idea behind 32bit Linux builds was to ensure 64 bit was the same as 32 bit when we were porting the game to 64 bit. Now that Ryan's PR bringing 64 bit compatibility fixes is in, there is a lower chance that we will find bugs because of that. At this point, maintaining compatibility with 32 bit Linux makes less sense because it is "one more platform to support" and not "the reference implementation". This project aims to support current-day platforms, and 32 bit Linux is not one of them.
Yes, publishing 32-bit Linux builds makes no sense.
If 32-bit Windows msvc builds stick around it might be helpful for Linux devs to have 32-bit clang/gcc targets (which can also be build locally) and not just a single GitHub target. Just building Release should be enough for that, as the tests and the compiler errors and warnings are the only interesting output.
The idea behind 32bit Linux builds was to ensure 64 bit was the same as 32 bit when we were porting the game to 64 bit. Now that Ryan's PR bringing 64 bit compatibility fixes is in, there is a lower chance that we will find bugs because of that.
In that case, you should know that the fixes in this PR are not the only uses of architecture specific sizes.
Now that Windows is also on its way to being totally 64bit, we'd rather not maintain a full 32bit Linux build. I bet some things are already broken, I don't want to pretend that we support it.