git: fix darwin to linux cross-compilation

[szlend]

Git uses uname for platform detection in some places which breaks cross-compilation from darwin to linux.

We can use the deterministic-host-uname package to replace uname with a mock mimicking the host's platform.

$ nix build -f . pkgsCross.aarch64-multiplatform.gitMinimal -L --print-out-paths
/nix/store/k25gxwp5xh06d70dxaw6ha33ajig5ssa-git-minimal-aarch64-unknown-linux-gnu-2.46.0

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

Just to check: We really want it for the host platform here, not the build platform? That’s kinda screwed up.

[szlend]

Just to check: We really want it for the host platform here, not the build platform? That’s kinda screwed up.

@emilazy When compiling natively, buildPlatform == hostPlatform, so there shouldn't be any issues.

However when cross-compiling, you can see that the configuration scripts rely on uname a lot to make architectural build decisions:

• https://github.com/git/git/blob/ef8ce8f3d4344fd3af049c17eeba5cd20d98b69f/config.mak.uname
• https://github.com/git/git/blob/ef8ce8f3d4344fd3af049c17eeba5cd20d98b69f/config.mak.dev

In these cases we want the configuration script to think that we're building for the host platform. From what I could gather there's no way to override this other than swapping in a mock uname.

That’s kinda screwed up.

Don't get me wrong, this is definitely a nasty hack and ideally upstream would make it possible to explicitly set the host platform. Though on the other hand it's kind of neat that you can just throw in a mock host-based uname and not have to worry about patching configuration scripts.

[emilazy]

Yeah, okay. It might be better for us to patch those uname_* variables (or just set them in makeFlags? I forget if those take precedence over variables in the Makefile), and ideally upstream would fix this, but this minimal fix seems reasonable. This causes a lot of rebuilds, so please retarget to the staging branch. A comment explaining why it’s necessary would be great too.

[szlend]

Overriding these variables using makeFlags does work to my surprise.

Something like this:

makeFlags = [
  "prefix=\${out}"
  "uname_S=${deterministic-host-uname.uSystem}"
  "uname_M=${deterministic-host-uname.processor}"
  "uname_O=${deterministic-host-uname.operatingSystem}"
  "uname_R=${deterministic-host-uname.modDirVersion}"
]

Though I feel a bit uncomfortable relying on internal details of the deterministic-uname derivation. I'm not sure if this is actually much better. Maybe deterministic-uname could expose a "public API" through passthru? Happy to go with this approach if preferred though.

I could also compute these values myself, at the cost of adding a lot of complexity to an already large derivation.

[philiptaron]

Looks good!

[emilazy]

I’m fine with the current solution. If you could report it upstream to Git, that would be great.