| 25 Oct 2025 |
samasaur | build successful 🎉 | 17:51:31 |
samasaur | https://github.com/NixOS/nixpkgs/pull/455592 | 17:51:33 |
emily | K900: (we need a freeze exemption from the RMs to merge that) | 18:08:09 |
emily | (though I support it) | 18:08:14 |
K900 | Uhh | 18:08:38 |
K900 | No we don't? | 18:08:44 |
K900 | I guess technically this could be considered breaking behavior | 18:08:54 |
K900 | But come on | 18:08:57 |
emily | it's a breaking change when there's both a framework and a library with the same name | 18:09:37 |
emily | which is exactly what Qt is unhappy about | 18:09:42 |
emily | but I suppose there may not be many other examples than libnetwork/Network | 18:10:16 |
emily | I'm not totally confident this isn't going to blow some things up on staging though | 18:18:07 |
emily | but hopefully it will be manageable if it does | 18:18:20 |
samasaur | out of the list that qt uses (AppKit, CFNetwork, AssetsLibrary, Photos, AudioToolbox, ApplicationServices, Carbon, CoreFoundation, CoreServices, CoreGraphics, CoreText, CoreVideo, CryptoTok enKit, DiskArbitration, Foundation, IOBluetooth, IOKit, IOSurface, ImageIO, Metal, MobileCoreServices, QuartzCore, Security, SystemConfiguration, UIKit, CoreL ocation, CoreMotion, WatchKit, GameController, CoreBluetooth, AVFoundation, Photos, Contacts, EventKit, HealthKit, UniformTypeIdentifiers, Network, OpenGL), Network was the only example of a conflict | 18:19:54 |
samasaur | so i think it's only likely to cause problems if anything wants libnetwork.tbd or some third-party conflicting name | 18:20:25 |
samasaur | and it should be fixable with -DCMAKE_FIND_FRAMEWORK=LAST in cmakeFlags | 18:20:47 |
emily | I wonder what libnetwork.tbd is for | 18:21:41 |
samasaur | but yeah it is a breaking change. hopefully just theoretically and not in practice | 18:22:06 |
samasaur | --- !tapi-tbd
tbd-version: 4
targets: [ x86_64-macos, x86_64-maccatalyst, arm64-macos, arm64-maccatalyst,
arm64e-macos, arm64e-maccatalyst ]
install-name: '/usr/lib/libnetwork.dylib'
reexported-libraries:
- targets: [ x86_64-macos, x86_64-maccatalyst, arm64-macos, arm64-maccatalyst,
arm64e-macos, arm64e-maccatalyst ]
libraries: [ '/System/Library/Frameworks/Network.framework/Versions/A/Network' ]
...
| 18:22:58 |
samasaur | i don't really know how to read these but it looks like it just reexports Network.framework? | 18:23:14 |
emily | Randy Eckenrode: this code from booter.nix seems suspicious now:
# This is a hack for resolving cross-compiled compilers' run-time
# deps. (That is, compilers that are themselves cross-compiled, as
# opposed to used to cross-compile packages.)
postStage = buildPackages: {
__raw = true;
stdenv.cc =
if buildPackages.stdenv.hasCC then
if
buildPackages.stdenv.cc.isClang or false
# buildPackages.clang checks targetPackages.stdenv.cc (i. e. this
# attribute) to get a sense of the its set's default compiler and
# chooses between libc++ and libstdc++ based on that. If we hit this
# code here, we'll cause an infinite recursion. Since a set with
# clang as its default compiler always means libc++, we can infer this
# decision statically.
then
buildPackages.pkgsBuildTarget.llvmPackages.libcxxClang
else
buildPackages.gcc
else
# This will blow up if anything uses it, but that's OK. The `if
# buildPackages.stdenv.cc.isClang then ... else ...` would blow up
# everything, so we make sure to avoid that.
buildPackages.stdenv.cc;
};
| 19:32:00 |
emily | hmm | 19:32:26 |
emily | but I guess it's only for
else if (targetPackages.stdenv or stdenv).cc.isGNU then
self.libstdcxxClang
else
self.libcxxClang;
| 19:32:29 |
emily | so it's fine | 19:32:34 |
samasaur | ooh https://www.swift.org/blog/nightly-swift-sdk-for-android/ | 20:05:34 |
samasaur | not really relevant in a nixpkgs context afaik but interesting | 20:05:44 |
Randy Eckenrode | Maybe for cross to Android? | 20:56:29 |
samasaur | mm, yeah, i suppose so. i know very little about nix targeting mobile platforms | 21:25:08 |
Randy Eckenrode | I think it’s a thing, but you have to jump through some hoops to install the Android SDK. | 22:48:40 |
emily | I believe we have the NDK just packaged | 22:59:23 |