Question: Can nix-portable bundle binaries for a different architecture ?

[573]

Hello,

first thanks for your extraordinary contributions to nix !

In https://github.com/matthewbauer/nix-bundle/pull/69 you wrote

We could just pull a static proot binary from proot's gitlab like I did it with nix-portable.

I plan to do something similar, i. e. somehow pull the static nix-user-chroot aarch64 binary in nix-bundle. Just don't know where to start yet.

Is nix-portable's scope regarding bundling in some way similar to nix-bundle's ? I'm asking because I want to check if I could also use nix-portable to bundle a certain haskell package for the aarch64-linux target, see https://github.com/matthewbauer/nix-bundle/issues/80

[DavHau]

Currently nix-portable doesn't support anything else than x86_64-linux. So that would have to be the first thing to fix. The main reason that restricts its compatibility is that the static proot binary is pulled from proots original pipeline. (And they don't provide binaries for aarch64). Therefore we'd need to fix the static nix build for proot in nixpkgs first. It builds, but try executing it in a debian docker container and it will fail.

Theoretically the bundling mechanism used here could be carved out and used for other stuff as well. But currently the bundling logic is not separated from the nix-portable specific things.

Another feature that you would probably want by a general bundler is a cleanup procedure that makes sure the temporary unpacked binaries get deleted after process execution. The arx bundler, which nix-bundle is relying on, does that via trap AFAIK.

In general I think it could be a good approach to build a general bundler out of the nix-portable logic. Since it is all just nix based, we could achieve good customizability. Also the amount of dependencies we require on the target system is very minimal. Another good thing is, the nix-portable approach uses zip + zstd compression which is orders of magnitude faster upon execution compared to nix-bundle and achieves better compression ratio at the same time.

[573]

This is great news !

Glad to see there are chances to get something new on nix-bundle's and nix-portable's shoulders. In fact I tried / am trying multiple approaches getting static binaries. Especially when it comes to non-toplevel packages i. e. some haskell artifacts I guess it heavily depends on which ghc version is used etc. long read short: Even if they compile ldd on aarch64 in fact states a different outcome (still dynamic exe).

Another path taken was nix-copy-closure, but there the closure sizes are a real blocker (again when using haskell binaries especially) as my phone is low on storage.

Thus I am happy to have you join in as still the best option to me in this area seems to be some kind of bundling.

[573]

@DavHau would you mind joining ZuriHac this weekend (registration link) ? We could make this a project there.

[DavHau]

Sounds like a nice idea. I cannot yet tell how much I can get involved, because I will be traveling a bit this weekend. But I will try to allocate at least some time. When I register there, should I put some project name?

Another path taken was nix-copy-closure, but there the closure sizes are a real blocker (again when using haskell binaries especially) as my phone is low on storage.

I mean, in the end, the bundler will also just unpack the closure to some location on disk. That might just be temporary, but you still need the space. I guess building actual static binaries is the only way to prevent copying the closure.

Also, when bundling multiple apps separately, it might require even more disk space compared to pure nix, since both app archives might contain redundant store paths.

[573]

No hurries.

I still like the idea of a bundler and both nix-bundle and nix-portable provide useful shortcuts at least for executables with small to medium size closures. In my case and I cannot speak in general there are 2 or 3 apps I'd like to just have usable on aarch64 host.

Static cross compilation is still blocked for me via Template Haskell as I'm still in the process of figuring out how to utilize the iserv process to handle those compile time code executions on host instead of build platform. There is some light at the end of the tunnel currently at least it seems as I'm approaching successful run via iohk's haskell.nix but I'm still not sure the main road blocks are passed in the near future.

So yes, #static-proot might be a project title and maybe as 2nd milestone we try the cross build maybe not this weekend. 1st milestone could just be to extract proot build and make it static as you proposed.

[573]

@DavHau, regarding the static build of proot: https://github.com/t184256/nix-on-droid/search?q=proot-static