Cross-compiling a devShell

Help
1

Hello everyone :slight_smile:

I am working on a project with volunteers who usually use ARM Macbooks. Since we have some stuff going on in our devShell (nothing too major though I’d say) I would like to offer a binary cache. Luckily there’s cachix :slight_smile:

We are using gitlab.com and don’t have access to an aarch64 system in CI though. Can someone offer some insight into whether cross-compilation might be a fit for my usecase?

And, if you think that’s feasible, how to do it? We are using flake-utils for system-handling if that is relevant.

2

No.

Crosscompiling is only sufficient if you do no evaluation on the target.

Here you might need to either use emulated native builds or a volunteer who builds and pushes.

Or an arm build host for the CI.

3

@voydus I think cross-compiling emulated native compilation is a great fit here, you do not want every arm-based volunteer to recompile everything themselves.

As for how to do it: the devshell is just another derivation, you can build it with nix by adding

boot.binfmt.emulatedSystems = [ "aarch64-darwin" ];

to your config and then running

nix build .#devShells.aarch64-darwin.default

1 Like
4

The arm books would evaluate it, and come to a different conclusion and different hashes than the crossbuilder, as they do not crossbuild.

And this is not cross compiling.

5

And this is not cross compiling.

Indeed, this is emulated native compilation.

The arm books would evaluate it, and come to a different conclusion and different hashes than the crossbuilder, as they do not crossbuild.

Are you sure this would lead to a different hash?

6

Yes, as inputs are different.

an x86 GCC used for crosscompiling targetting arm has a different hash than an arm GCC to natively build for arm, and as hashes are based on the inputs of a derivation, changing the inputs will always result in different outputs.

7

But the argument does not hold up for emulated native compilation, the inputs are all the same and therefore the outputs too. Evaluating .#devShells.aarch64-darwin.default on x86_64-linux or “natively” on aarch64-darwin will lead to the same derivation.

8

Yes, the argument does not hold for native emulated, thats why I mentioned it as one of the solutions.

9

That’s the key information for me, sadly not the one I wanted to hear.
Do you know if the same issue applies to -darwin/-linux? I.e. could I build (realize?) the arm64-darwin devshell on an raspbery pi?

This is probably academic because of performance, but I’m still curious

Wait now I’m confused. I’ll compare hashes and see.

10

Not the first time today I just completely missed a line reading something…
My bad, sorry!

I should get my eyes and/or my head checked out

11

If it runs darwin…

The problem with darwin is, you need darwin to build for darwin. There are some licensing woes around it, enforced by the XCode package which needs to be available. I am not aware of any way around that.

2 Likes