diff options
Diffstat (limited to 'results/scraper/fex/1996')
| -rw-r--r-- | results/scraper/fex/1996 | 39 |
1 files changed, 39 insertions, 0 deletions
diff --git a/results/scraper/fex/1996 b/results/scraper/fex/1996 new file mode 100644 index 000000000..10b9270eb --- /dev/null +++ b/results/scraper/fex/1996 @@ -0,0 +1,39 @@ +Build thunks GuestLibs on other arm64 distros (say, Arch Linux) +Currently we rely on debian's `gcc-x86-64-linux-gnu` package to supply a working x86_64 cross-compiler on Debian/Ubuntu distros. But other distros (like Arch Linux) are missing such handy packages. + +I've done a bit of preliminary research, and it seems like these are our rough options: + +### Option One - Use clang instead: + +Clang helpfully includes compilers for all triples by default, and cross-compiling is simply a matter of passing the correct triple into clang/clang++. This seems like an elegant solution, we already require clang for thunk generation, why not use it for building thunks too. + +However... This solution *only* gets you a compiler. +The `gcc-x86-64-linux-gnu` package (and the `g++`/`multilib-i686` variants) actually pull in a bunch of other packages to supply a full libc and libc++ and other support libraries that our thunks need to build. If we go with the clang option, then we need to supply the missing include from somewhere else. + +But from where? We have a two potential options: + + * Most of the include files can be found in the host, though we will need to supply the missing x86 bits of linux headers, glibc and libstdc++. + * This option runs the risk that other random libraries will change their include files slightly depending on host arch, and might end up doing the wrong thing + * We will be missing the .so files, can we create our thunks without them? + * We just supply all the includes, either: + * a rootfs style download (generated along-side our rootfs? That would keep them in-sync) + * as a submodule + +### Option Two - Generate equivalent packages for Arch + +These packages are clearly useful for Debian, would be nice to have equivalents in Arch Linux ARM. + +There are some downsides to this approach: + + 1. these packages will be in AUR and will take a while to build from source (especially if people are building them on lower-end ARM SBCs, maybe we could supply equivalent binary packages?) + 2. We would need to maintain them + 3. It only fixes the issue for Arch Linux ARM and derivatives; Other distros still won't be able to build thunks. + +### Idea three - Just use a native x86 toolchain inside our rootfs + +This is an ugly and lazy option. Requires a large download (and probably unpacking the rootfs to install a compiler) + +------ + + +Whatever solution we go with, we should standardise across all distros, so we aren't using widely different approaches on different distros. I'm currently leaning towards Option One, with us packaging headers, not just for libc/libstdc++, but all libraries we thunk. \ No newline at end of file |