Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Cross Compiling #45

Open
4 tasks
Thra11 opened this issue Apr 21, 2019 · 1 comment
Open
4 tasks

Feature: Cross Compiling #45

Thra11 opened this issue Apr 21, 2019 · 1 comment

Comments

@Thra11
Copy link

Thra11 commented Apr 21, 2019

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?

@Thra11
Copy link
Author

Thra11 commented May 6, 2019

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant