!lheuhImcToQZYTQTuI:nixos.org

Nix on macOS

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

Load older messages


SenderMessageTime
24 Oct 2025
@reckenrode:matrix.orgRandy EckenrodeIt was. I added it in preparation for supporting Swift Build. If I got the name wrong, I can fix it. I was going by the keys it references in its source. If people are that annoyed by the warnings in xcbuild, they can be patched out.10:40:09
@emilazy:matrix.orgemily I take it Swift Build has no xcrun or xcode-select, right? 10:51:30
@ihar.hrachyshka:matrix.orgIhar Hrachyshka now that target sdk is 14.4, should we make blas == Accelerate? 10:51:59
@emilazy:matrix.orgemilywe should keep a list of "if you feel like writing a compatible FOSS replacement for this Apple tool we will love you forever"10:52:12
@emilazy:matrix.orgemilyPlistBuddy, xcrun, ibtool, ...10:52:28
@emilazy:matrix.orgemilyditto...10:52:31
@emilazy:matrix.orgemilythe dearly missed paparodeo ran into crashes with some packages using Accelerate and had to give them OpenBLAS explicitly. I'm not sure why10:52:58
@emilazy:matrix.orgemilyI'd probably want us to investigate those before doing the switch10:53:10
@reckenrode:matrix.orgRandy Eckenrode It’s just the engine used by Xcode. It provides a binary, but the CLI is incompatible. Longer term, we could use Swift Build to provide a compatible(-enough) xcode-build. 11:03:29
@reckenrode:matrix.orgRandy Eckenrode Same for xcrun. Just write a good enough replacement in Swift. 11:04:02
@reckenrode:matrix.orgRandy EckenrodeIt’s not fully compatible. There are some differences numerically. I ran into test failures trying to use it with something and didn’t bother after that.11:04:53
@ihar.hrachyshka:matrix.orgIhar Hrachyshkanumpy (in staging) is now Accelerate since it was picked up automatically by the build system. scipy is not (I have a patch for this). when you say "test failures", do you mean nix build invoked or something else? (basically, q is: are we ok to switch a package - or packages - if they build / pass test suites)11:06:04
@reckenrode:matrix.orgRandy EckenrodeIt was the package’s test suite. I can’t remember whether it was numpy or scipy, but it was a Python package.11:07:21
@ihar.hrachyshka:matrix.orgIhar Hrachyshkaack. scipy and numpy pass. maybe it's something else.11:08:36
@reckenrode:matrix.orgRandy EckenrodeThey could have also fixed support.11:08:56
@reckenrode:matrix.orgRandy EckenrodeIf the tests pass, switching seems reasonable, especially if we are now at the supported platform level.11:09:44
@ihar.hrachyshka:matrix.orgIhar Hrachyshka scipy/numpy maintainer asked in the patch switching scipy to accelerate if we should have blas == Accelerate; but I think regardless we may want to have a blasAccelerate that we could pass through override args to try different implementations if needed. 11:09:48
@ihar.hrachyshka:matrix.orgIhar Hrachyshkain other news, something from the latest staging-next broke firefox pretty bad on darwin. it crashes when showing a png for favicon. I'm doing a bisect but it's 14 steps of world rebuilds and will take some time. I hope it's not the libcxx mad-emoji-throwing-a-table change.11:13:59
@reckenrode:matrix.orgRandy EckenrodeDoes upstream Firefox link against the system libc++?11:14:36
@ihar.hrachyshka:matrix.orgIhar Hrachyshka

firefox-bin-unwrapped: (their build)

otool -L result/Applications/Firefox.app/Contents/MacOS/firefox
result/Applications/Firefox.app/Contents/MacOS/firefox (architecture x86_64):
	@rpath/libmozglue.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 3502.1.255)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
result/Applications/Firefox.app/Contents/MacOS/firefox (architecture arm64):
	@rpath/libmozglue.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 3502.1.255)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
11:16:43
@ihar.hrachyshka:matrix.orgIhar Hrachyshka

our build:

otool -L result/Applications/Firefox.app/Contents/MacOS/firefox
result/Applications/Firefox.app/Contents/MacOS/firefox:
	@rpath/libmozglue.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 3502.1.255)
	/nix/store/jl1421wiawqdgasrqqwd4d4jznvimfma-gettext-0.25.1/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.4.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
11:17:27
@reckenrode:matrix.orgRandy EckenrodeThey both are. I hope it’s not that change then.11:19:40
@ihar.hrachyshka:matrix.orgIhar Hrachyshka

I have an alternative path to explore (adding a lot of debug messages in their png encoder to catch what happens there) but I'm lazy and want to bisect first. The crash is from access to an invalid memory address, and the code in question is:

void nsPNGEncoder::ConvertHostARGBRow(const uint8_t* aSrc, uint8_t* aDest,
                                      uint32_t aPixelWidth,
                                      bool aUseTransparency) {
  uint32_t pixelStride = aUseTransparency ? 4 : 3;
  for (uint32_t x = 0; x < aPixelWidth; x++) {
    const uint32_t& pixelIn = ((const uint32_t*)(aSrc))[x];
    uint8_t* pixelOut = &aDest[x * pixelStride];

    uint8_t alpha = (pixelIn & 0xff000000) >> 24;
    pixelOut[pixelStride - 1] = alpha;  // overwritten below if pixelStride == 3

The last line crashes. Either pixelOut is null, or the caller passes a non-transparent buffer (3-bytes per pixel while also requesting transparency).

Initially thought it's the new 144 version but 1) their crash reporter database caught some failures on 140 and 2) no relevant changes in the PNG encoder code of theirs that I could spot.

11:33:41
@alexfmpe:matrix.orgalexfmpeI wonder if rosetta 2 can/should be worked into stdenv.*Platform.{canExecute, selectEmulator}16:35:30
@alexfmpe:matrix.orgalexfmpeor it's best called 'outside' for the whole nix-build process16:36:09
@prince213:matrix.orgprince213I think it can16:47:50
@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

Show newer messages


Back to Room ListRoom Version: 6