[staging-next] xar: cannot build on x86_64-linux

[Frontear]

Describe the bug

pkgs.xar cannot be built on any system outside of *-darwin (and maybe BSD systems) due to the usage of a BSD/Darwin specific fnctl value F_GETPATH in xar/lib/archive.c.

I believe this is a regression since pkgs.xar has worked before (master works), and the last time it was touched was by @reckenrode in #346043.

Steps To Reproduce

Steps to reproduce the behavior:

1. nix build github:NixOS/nixpkgs?rev=6968567d601da88ff67834173c9384f7a7be3d3d
2. Fails to build lib/archive.o due to above

Expected behavior

I assume a patch to exclude this behaviour, or if that's not possible (how did older pkgs.xar versions work, is this new?) then marking as darwin-platform only.

Notify maintainers

cc @copumpkin [maintainer]
cc @reckenrode [last commiter]

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.58, NixOS, 24.11 (Vicuna), 24.11.20241025.18536bf`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Lix, like Nix) 2.91.1
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux, x86_64-v4-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/frontear/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/frontear/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/frontear/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/frontear/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/99w9bip89dil7f2c7ngn2nkzlkld5gc0-lix-2.91.1/share`
 - nixpkgs: `/nix/store/bmgbhh46sapjn6c846djxygdvxy9djlj-input-farm/nixpkgs`

---

Add a 👍 reaction to issues you find important.

[emilazy]

@tie ported it to Linux in #329721. I guess they added more use of macOS APIs in the version bump. I’ll see if I can take a look.

Out of curiosity, what do you use that depends on this on Linux?

[Frontear]

@tie ported it to Linux in #329721. I guess they added more use of macOS APIs in the version bump. I’ll see if I can take a look.

Out of curiosity, what do you use that depends on this on Linux?

I'm actually currently working on getting cross compilation working from x86_64-linux (and maybe more) to x86_64-darwin at the moment actually. I was inspired by https://github.com/tpoechtrager/osxcross to attempt such a thing, after seeing a proof-of-concept + real results in large-scale software.

Currently all this work is happening out-of-tree on a local repository. I ran into this issue trying to use the darwin rework #346043 to attempt a minimal build of the SDKs (not building through Nix), and since I could readily use it before, I figured it was a regression worth bringing up.

[emilazy]

It’d be good to coordinate that work in the Matrix macOS room. Linux‐to‐Darwin cross has been discussed before, but there are a bunch of issues we need to avoid. For instance, cctools-port is frequently behind, so we would likely want to extend our current cctools/ld64 portability patches instead.

I believe our SDK derivation should basically just work as long as the relevant tools do. stdenv will need work (AIUI).

[Frontear]

It’d be good to coordinate that work in the Matrix macOS room. Linux‐to‐Darwin cross has been discussed before, but there are a bunch of issues we need to avoid. For instance, cctools-port is frequently behind, so we would likely want to extend our current cctools/ld64 portability patches instead.

I believe our SDK derivation should basically just work as long as the relevant tools do. stdenv will need work (AIUI).

Glad to hear! I was a little concerned with directly messing with Nixpkgs things since I expected I'd bump into a lot of hiccups, particularly since this task isn't exactly "supported". Nonetheless, I'll start with trying to slowly piece together the smaller bits through the available derivations and see where I can go from there.

[reckenrode]

I opened #352507 to try to fix the Linux build failure. I confirmed it built at least. The function is exported by libxar.so but not used in xar as far as I can tell.

[reckenrode]

Re: cctools-port

When I updated cctools and ld64, cctools-port had not yet updated to the latest release. It wasn’t clear when it would be updated, so I opted to do a new port with a small set of vendored patches. It has since been, but I think it’s preferable to stick with our own patch set because it can be tailored to the needs of nixpkgs.

It’s possible I may be able to work on the Linux port for 25.05 (though 25.11 is more likely). The most likely approach is replacing Darwin-specific APIs with standards-based equivalents (e.g., Darwin-specific byteswap functions). Like the corecrypto replacement I did, these will be used on both platforms.

Longer term (once ld64 is fully dropped from Xcode), we should probably fork it into the NixOS org for further cleanup.