Before that, waddlesplash (or was it axeld?) suggested to redo it in a slightly different way. I didn’t look at it close enough to see if the change was really useful, but it would need basically rewriting the whole change with a different approach.
There were not much changes to the buildsystem, from that point of view you just configure your build as an hybrid with 64 bit primary arch and 32 bit secondary. The “magic” happens in syscall handlers.
If I remember correctly, in korli’s implementation, each syscall will determine if the caller app is 32bit, and convert pointers to 64bit.
Waddlesplash wanted to introduce stparate syscalls for the 32 and 64 bit versions whenever pointers are involved, and convert the syscall numbers. I’m not sure what the supposed benefits would be.
While comparing these approaches, we may also want to think about what a qemu-user inspired system would look like, for example to run x86 binaries on ARM systems. We should probably pick the one tqat makes that easier in the future?
A follow up to this would be allowing two secondary archs, x86 and x86_gcc2. They were both tested separately, or maybe at the same time by manually setting up a bootable partition with all needed packages. It would also require x86_gcc2 packages as secondary arch, which we currently don’t provide.
#ully integrating this may require re-thinking the concept of “secondary” arch and make all architectures be “primary”, that would mean the packages are the same when using x86_gcc2 as a secondary arch over x86_64, or as a primary arch on a 32bit system. Currently this would require packages with different internal organization (library paths, etc).