!lheuhImcToQZYTQTuI:nixos.org

Nix on macOS

1162 Members
“There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org188 Servers

Load older messages


SenderMessageTime
24 Oct 2025
@prince213:matrix.orgprince213I saw an example before16:47:55
@reckenrode:matrix.orgRandy EckenrodeIt is possible to set it up as an emulator in nixpkgs. I have started to do it a few times then stopped because it seems pointless.16:49:02
@reckenrode:matrix.orgRandy Eckenrode Not many things use emulators. canExecute is not about emulation, so it doesn’t help with tests when cross-compiling. 16:50:01
@reckenrode:matrix.orgRandy EckenrodeIntel support in nixpkgs is (very probably) being dropped for 26.11, which likely means July next year. It doesn’t seem worth the effort to develop new features for Intel or Rosetta 2 just to remove them after 26.05 is released.16:52:54
@alexfmpe:matrix.orgalexfmpeoh I thought it would last a couple more years16:55:38
@alexfmpe:matrix.orgalexfmpeyeah not much point to add something after 25.11 that gets dropped by 26.05 lol16:56:07
@reckenrode:matrix.orgRandy Eckenrodehttps://github.com/NixOS/nixpkgs/pull/41556616:56:40
@reckenrode:matrix.orgRandy EckenrodemacOS 27 is dropping hardware support. macOS 28 is dropping Rosetta 2 except for some unspecified compatibility intended for games.16:57:37
@reckenrode:matrix.orgRandy EckenrodeThe ecosystem appears to be running away from it already.16:57:54
@reckenrode:matrix.orgRandy EckenrodeRust demoted it to tier 2. The GitHub runner was pulled then restored, but it is limited to macOS 15. Who knows for how long. Once it’s gone, Intel support will probably start bitrotting.16:59:23
@reckenrode:matrix.orgRandy EckenrodeFrom the nixpkgs side, x86_64-darwin is the slowest platform to build. Being able to drop it will free up builders to build aarch64-darwin, which should make cycles go faster.17:00:23
@eexist:matrix.orgstderr joined the room.18:00:15
@esperlily:matrix.orgEsperLily [she/her]

the name looks right, although i suppose i didn't actually check to make sure there wasn't some hidden character or some typo i just didn't see. i really don't know why xcrun is printing a warning about that with the nixpkgs SDK when the Xcode SDK has what looks like the exact same key. Does Swift Build care about that particular key?

My bigger concern is what I mentioned in the Nixpkgs / NixOS contributions room, which is that when I try to use Xcode to build a project with the nixpkgs SDK (not Xcode-in-nixpkgs but /usr/bin/xcodebuild, though I don't know if it actually makes a difference), I end up with what looks like a neverending stream of these warnings, several per second, with no other output. I don't know if the warning itself is actually a problem here or if there's some other reason why Xcode doesn't seem to actually be doing anything except printing these warnings

20:08:59
@emilazy:matrix.orgemily /usr/bin/xcodebuild will probably indirect through $DEVELOPER_DIR? 20:18:41
@emilazy:matrix.orgemily so is probably calling into xcbuild.xcrun etc. 20:18:54
@esperlily:matrix.orgEsperLily [she/her] /usr/bin/xcrun produces the same warning 20:19:24
@esperlily:matrix.orgEsperLily [she/her] oh wow what, /usr/bin/xcrun actually invokes xcbuild.xcrun? 20:20:19
@emilazy:matrix.orgemily everything in /usr/bin is just a stub that looks up the current developer directory 20:20:33
@esperlily:matrix.orgEsperLily [she/her] but xcrun -find xcrun doesn't find anything 20:20:33
@esperlily:matrix.orgEsperLily [she/her]yeah it's a stub that looks it up with the xcrun machinery. xcrun should be the one thing that isn't a stub20:20:46
@emilazy:matrix.orgemily
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ mkdir -p usr/bin

shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ cat >usr/bin/xcrun
#!/usr/bin/env bash
echo oops

shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ chmod +x usr/bin/xcrun

shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ DEVELOPER_DIR=(pwd) /usr/bin/xcrun
oops
20:21:50
@emilazy:matrix.orgemily I think it recurses if there's another xcrun. 20:22:08
@emilazy:matrix.orgemily not even --help etc. do anything. 20:22:16
@esperlily:matrix.orgEsperLily [she/her]wow20:22:41
@emilazy:matrix.orgemily I think /usr/bin/xcrun is exactly like /usr/bin/clang 20:22:48
@emilazy:matrix.orgemily they call the thing from libselect or whatever it's called to find the xcrun path relative to the developer dir and then run it 20:22:59
@emilazy:matrix.orgemilyand then the rest of the library calls are in that binary20:23:13
@emilazy:matrix.orgemily
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ DEVELOPER_DIR=(pwd) /usr/bin/clang
oops
20:23:16
@emilazy:matrix.orgemily so my guess is there's an infinite recursion where it's trying to get xcrun to run something but then xcrun can't find the thing and it falls back to /usr/bin which then etc… 20:24:11
@esperlily:matrix.orgEsperLily [she/her] but there is no xcrun in the normal Xcode developer dir (there is a usr/lib/libxcrun.dylib though) 20:24:19

Show newer messages


Back to Room ListRoom Version: 6