| 21 Oct 2025 |
 dbaynard | * > nix build -L '.#libtree.tests.checkCoreUtils' --no-link --print-out-paths
/nix/store/40xm11r0sklkl4x5cp8xdckp5sha0yfd-libtree-ls-test
> nix build -L '.#libtree.tests.checkCoreUtils' --no-link --print-out-paths | xargs bat
───────┬──────────────────────────────────────────────────────────────────────────────────────────────
│ File: /nix/store/40xm11r0sklkl4x5cp8xdckp5sha0yfd-libtree-ls-test
───────┼──────────────────────────────────────────────────────────────────────────────────────────────
1 │ /nix/store/x2s54dnz7kd4vbslfcv1x3g69p30fz7y-coreutils-aarch64-unknown-linux-gnu-9.7/bin/ls
2 │ ├── libacl.so.1 [runpath]
3 │ │ └── libattr.so.1 [runpath]
4 │ ├── libattr.so.1 [runpath]
5 │ └── libgmp.so.10 [runpath]
───────┴──────────────────────────────────────────────────────────────────────────────────────────────
This is the test result, making the above change to use the pkgsCross (but not pkgsStatic!) coreutils.
| 23:47:21 |
| dbaynard | Thanks for your help. I should have been more explicit that this is working, reasonably, for me (I haven't used all the functionality but I have found it useful as a tool that works on macos that can analyze ELFs). I'll ask in the cross compile channel, when I return to this. | 23:50:07 |
 emily | no worries :) | 23:50:38 |
| emily | I agree with Randy Eckenrode about the best way to test it | 23:50:44 |
| emily | pull in clang-unwrapped on all platforms and make a couple basic .sos with --target= | 23:51:16 |
| emily | no need for pkgsCross | 23:51:25 |
| 22 Oct 2025 |
 Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/454402 | 00:37:38 |
| Randy Eckenrode | Darwin source release updates to 15.6 | 00:37:42 |
| Randy Eckenrode | * | 00:39:25 |
| emily | will try to take a look at this tomorrow | 00:39:43 |
| Randy Eckenrode | There were some build changes, but I rolled most of it into the 14.0 PR. | 00:40:19 |
| emily | did you see https://github.com/NixOS/nixpkgs/pull/453094 and https://github.com/NixOS/nixpkgs/pull/453106 btw? | 00:40:26 |
| emily | (these actually come out of… me looking into .override interfaces) | 00:42:03 |
| emily | (long story) | 00:42:42 |
| Randy Eckenrode | I got the mkAppleDerivation interface from the FreeBSD stuff. Is there no way to use it after https://github.com/NixOS/nixpkgs/pull/453094 without a full stdenv? | 00:47:27 |
| emily | it's kinda impossible to properly support with finalAttrs in general I think | 00:55:19 |
| emily | because what gets passed as finalAttrs could depend on the stdenv in theory | 00:55:29 |
| emily | it only affects a single package so I decided it wasn't worth messing with (I'd rather move mkAppleDerivation over to use hooks etc. instead) | 00:56:07 |
| emily | (but the stdenv is only determined by finalAttrs.noCC/finalAttrs.noBootstrap) | 00:56:20 |
| emily | unifdef already requires stdenv anyway, so darwin.AvailabilityVersions is not really helped by avoiding it, it'd mostly matter for cross scenarios I suppose | 00:57:57 |
| Randy Eckenrode | Overall, it seems fine. What did you have in mind about hooks and helper functions? The point of mkAppleDerivation is to minimize boilerplate in the source release derivations. The Xcode version check is already a hook. The Meson stuff can’t be a hook. It’s horrible, but I would like to work towards using Swift Build with a private SDK to build the source releases instead of using Meson. | 01:15:19 |
| Randy Eckenrode | * Overall, it seems fine. What did you have in mind about hooks and helper functions? The point of mkAppleDerivation is to minimize boilerplate in the source release derivations. The Xcode version check is already a hook. The Meson stuff can’t be a hook. It’s horrible, but I would like to work towards using Swift Build with an internal SDK to build the source releases instead of using Meson. | 01:15:31 |
| Randy Eckenrode | I considered adding dtrace, cherry-picking from the PR, but I didn’t want to sink a lot more time into the update. | 01:16:42 |
| emily | the Meson stuff could be a hook other than the magic filename lookup stuff, which is a bit evil anyway IMO (and IIRC caused issues with the DTrace PR?), but I agree that Swift Build would be nice. src could be set with a helper function and meta could be inherited | 01:19:01 |
| emily | but the reason to switch to lib.extendMkDerivation is that it makes .overrideAttrs etc. actually work properly | 01:19:54 |
| emily | and avoids the results having a somewhat dodgy .override (albeit one that is clobbered by callPackage in practice) | 01:20:21 |
| Randy Eckenrode | The magic filename stuff is largely the point of the Meson stuff. It’s to reduce the boilerplate of copying in the files and setting the version/etc. With Swift Build, we don’t need that stuff at all. You could just use swiftBuildHook (or whatever it gets called) and the internal SDK. | 01:20:31 |
| Randy Eckenrode | Inheriting meta seems worse. You would end up with every derivation copying and pasting meta = { description = "blah"; inherit (standardMeta) etc etc etc; }. | 01:21:36 |
| emily | it could be done with (magicMesonHook ./.) or similar though | 01:22:39 |
| Randy Eckenrode | True. | 01:23:03 |
