Feature: Cross Compiling
Opened this issue · 1 comments
I know the ReadMe explicitly states that the target architecture must match the host architecture. However, I thought I would experiment to see if it might be possible for nix-bundle to support cross-compilation in the future.
What I have so far is a working proof of concept which shows that is possible for nix-bundle to produce a runnable bundle for a different target architecture. At the moment, the target architecture is hard-coded and it requires a manual tweak to the startup script.
Changes can be found here:
nix-bundle
nixpkgs
What needs to be done:
- Finish and merge #58606 (or similar) to strip cross-compiled packages (Not sure this is essential, but decompressing 200MB of unneeded packages is undesirable and really slows testing down.)
- Put nix-user-chroot into nixpkgs. Again, not sure if this is essential, but it's the easiest way to have
pkgsCross.<target-platform>.nix-user-chroot
available - Either deduce or pass in the target platform and build nix-user-chroot for that platform (currently hardcoded)
- I had to manually edit the startup script as follows:
LD_PRELOAD="\
./nix/store/28nb6zzh6mjj3706s0w4jyvvh5hb4dnb-armv7l-unknown-linux-gnueabihf-stage-final-gcc-7.4.0-lib/lib/libstdc++.so.6 \
./nix/store/2mm8gpnipz6i27s2314wm35kdih2kimm-glibc-2.27-armv7l-unknown-linux-gnueabihf/lib/libm.so.6 \
./nix/store/28nb6zzh6mjj3706s0w4jyvvh5hb4dnb-armv7l-unknown-linux-gnueabihf-stage-final-gcc-7.4.0-lib/lib/libgcc_s.so.1 \
./nix/store/2mm8gpnipz6i27s2314wm35kdih2kimm-glibc-2.27-armv7l-unknown-linux-gnueabihf/lib/libc.so.6" \
./nix/store/2mm8gpnipz6i27s2314wm35kdih2kimm-glibc-2.27-armv7l-unknown-linux-gnueabihf/lib/ld-linux-armhf.so.3 nix/store/lh0xjxrg149glgpxwq5sysg71f20z36l-nix-user-chroot-2c52b5f-armv7l-unknown-linux-gnueabihf/bin/nix-user-chroot -n ./nix -- nix/store/j5z84b29h6nzk19v4py0ki28w4kkmwwy-hello-2.10-armv7l-unknown-linux-gnueabihf/bin/hello $@
Presumably the bit that writes the script should be able to write these paths in, but I'm not sure what to put in ${}
to get something like /nix/store/28nb6zzh6mjj3706s0w4jyvvh5hb4dnb-armv7l-unknown-linux-gnueabihf-stage-final-gcc-7.4.0-lib
. I assume that the problem is that nix-user-chroot is expecting its libs to be in the usual absolute store paths, not relative to the current directory, so alternatively, it might be possible to either fix-up the library paths in nix-user-chroot binary so that it expects libs relative to itself, or to statically link it.
What do you think? Is this something that you'd want to support in nix-bundle?
Thinking about this, how does nix-user-chroot usually find the libs it depends on? At the point when it is executed, the libs have been extracted, but the user namespace which mounts them under /nix hasn't been set up yet (that's nix-user-chroot's job)