| 24 Oct 2025 |
 samasaur | will revisit tomorrow | 05:35:03 |
 EsperLily [she/her] | hmm, xcrun from a nix-shell on current master is printing a warning that isn't happening with nixpkgs from a few days ago (warning: unhandled Platform key FamilyDisplayName) | 08:08:47 |
| EsperLily [she/her] | i can't be 100% positive since i'd have to actually rebuild the whole darwin SDK to be sure, but I think this was caused by https://github.com/NixOS/nixpkgs/pull/445094 | 08:23:07 |
| EsperLily [she/her] | looking at my Xcode developer dir, I also see that FamilyDisplayName is found within ./Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.plist (as the key PlatformFamilyDisplayName) and it's not there in the nixpkgs SDK version, so I'm wondering if maybe that's the difference? | 08:30:53 |
| EsperLily [she/her] | hmm, i just copied the nixpkgs SDK and edited that file to insert PlatformFamilyDisplayName and it didn't fix it. But editing Platforms/MacOSX.platform/Info.plist to remove FamilyDisplayName does remove the warning | 08:34:59 |
 emily | ok then maybe look at my CMake patches | 10:23:57 |
| emily | I don't feel good about doing that to Qt without understanding why | 10:24:04 |
| emily | my guess is it might actually be an upstream CMake change | 10:24:20 |
| emily | but if not then it's plausible it's the stuff I did to get rid of the mangling hook for the 4 update | 10:24:35 |
 Randy Eckenrode | It 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 |
| emily | I take it Swift Build has no xcrun or xcode-select, right? | 10:51:30 |
 Ihar Hrachyshka | now that target sdk is 14.4, should we make blas == Accelerate? | 10:51:59 |
| emily | we 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 |
| emily | PlistBuddy, xcrun, ibtool, ... | 10:52:28 |
| emily | ditto... | 10:52:31 |
| emily | the dearly missed paparodeo ran into crashes with some packages using Accelerate and had to give them OpenBLAS explicitly. I'm not sure why | 10:52:58 |
| emily | I'd probably want us to investigate those before doing the switch | 10:53:10 |
| Randy 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 |
| Randy Eckenrode | Same for xcrun. Just write a good enough replacement in Swift. | 11:04:02 |
| Randy Eckenrode | It’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 | numpy (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 |
| Randy Eckenrode | It 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 | ack. scipy and numpy pass. maybe it's something else. | 11:08:36 |
| Randy Eckenrode | They could have also fixed support. | 11:08:56 |
| Randy Eckenrode | If the tests pass, switching seems reasonable, especially if we are now at the supported platform level. | 11:09:44 |
| Ihar 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 | in 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 |
| Randy Eckenrode | Does upstream Firefox link against the system libc++? | 11:14:36 |
| Ihar 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 | 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 |
