Library Forwarding: Make building on weak cross-compiling setups easier

[neobrain]

ARM64 Ubuntu provides both an x86 cross-compiler and corresponding glibc/stdlibc++ libraries, which makes cross-compiling FEX's guest library wrappers very easy. Sadly most other distributions only ship the compiler without any libraries/headers at all. In such environments, it can be easier to compile only the host-side libraries while offloading builds of the guest libraries to another machine / VM.

This PR adds two main features to make such fallback setups possible:

• Guest wrappers may now be built separately from the main project by running cmake ../ThunkLibs/CMakeLists.txt -DX86_32_TOOLCHAIN_FILE=`realpath ../toolchain_x86_32.cmake` -DX86_64_TOOLCHAIN_FILE=`realpath ../toolchain_x86_64.cmake` -DX86_DEV_ROOTFS=/ from a dedicated build folder.
• The new X86_DEV_ROOTFS CMake setting can be used to provide a development x86 rootfs, from which standard headers will be read. (Specifically, Ubuntu requires these packages: libstdc++-12-dev-amd64-cross libstdc++-12-dev-i386-cross libstdc++-12-dev libc6-dev-amd64-cross libc6-dev-i386-cross linux-libc-dev-amd64-cross linux-libc-dev-i386-cross)

[alyssarosenzweig]

In the case where we have a working x86 cross compiler when building on arm64, and can procure a x86 rootfs but without the proper multilib integration, does X86_DEV_ROOTFS provide the necessary glue to build thunks without needing a separate machine/VM? If so, I think that sounds like a decent approach for Fedora. It would be great to get some documentation (either in-tree or contributed to wiki) about how to use these new options to build fex on such weak setups.

[neobrain]

In the case where we have a working x86 cross compiler when building on arm64, and can procure a x86 rootfs but without the proper multilib integration, does X86_DEV_ROOTFS provide the necessary glue to build thunks without needing a separate machine/VM? If so, I think that sounds like a decent approach for Fedora. It would be great to get some documentation (either in-tree or contributed to wiki) about how to use these new options to build fex on such weak setups.

It might work without a VM, but I haven't tested it. You'd have to add the dev rootfs paths to the CMake toolchain files in our project root so that the CMake targets in GuestLibs/CMakeLists.txt can also find the headers/libraries. Definitely interested to see someone try that out!

[neobrain]

Realized we can achieve the same effect by using --sysroot and re-adding the global /usr/include directory for library headers, which is much cleaner than adding hardcoded include directories manually.

[neobrain]

Something's off about this. I'm getting weird RPATH errors without ../, but with ../ it's clearly putting the data in the wrong folder.

[asahilina]

I tried this out on Fedora and successfully got thunks to work with a hacked up GCC sysroot and custom target files (because Fedora's x86 cross compilers aren't built the same as the native ones so they need a bunch of overrides).

I think if this is merged as-is with just these two fixes, we're basically good for the x86 sysroot approach!

[asahilina]

This should be ${X86_32_TOOLCHAIN_FILE}

[asahilina]

This should be ${X86_64_TOOLCHAIN_FILE}

[asahilina]

That said, the first two commits on their own are fairly useless right now. The issue is that the host thunks build relies on having the guest environment available in order to do the data_layout comparison. To make that work, we'd have to modify thunkgen to make it able to serialize the guest data_layout, generate that on the guest builder, and use those serialized files to build the host thinks.

I'll try to extract just the rootfs change and verify that it's sufficient for a Fedora build if the right sysroot is available, so we can merge that now and leave the rest for later.

[asahilina]

Submitted just the last commit as #4230 (rebased).