From daa79a1d2db7909a314bb8aa0adf514147a1191e Mon Sep 17 00:00:00 2001 From: Randy Eckenrode Date: Wed, 1 Nov 2023 20:56:50 -0400 Subject: darwin.stdenv: use CoreFoundation instead of CF MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch switches the CoreFoundation on x86_64-darwin from the open source swift-corelibs-foundation (CF) to the system CoreFoundation. This change was motivated by failures building packages for the current staging-next cycle #263535 due to an apparent incompatibility with the rpath-based approach to choosing CF or CoreFoundation and macOS 14. This error often manifests as a crash with an Illegal Instruction. For example, building aws-sdk-cpp for building Nix will fail this way. https://hydra.nixos.org/build/239459417/nixlog/1 Application Specific Information: CF objects must have a non-zero isa Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x7FF8094DD640) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x7ff8094dd640 CF_IS_OBJC.cold.1 + 14 1 CoreFoundation 0x7ff8094501d0 CF_IS_OBJC + 60 2 CoreFoundation 0x7ff8093155e8 CFRelease + 40 3 ??? 0x10c7a2c61 s_aws_secure_transport_ctx_destroy + 65 4 ??? 0x10c87ba32 aws_ref_count_release + 34 5 ??? 0x10c7b7adb aws_tls_connection_options_clean_up + 27 6 ??? 0x10c596db4 Aws::Crt::Io::TlsConnectionOptions::~TlsConnectionOptions() + 20 7 ??? 0x10c2d249c Aws::CleanupCrt() + 92 8 ??? 0x10c2d1ff0 Aws::ShutdownAPI(Aws::SDKOptions const&) + 64 9 ??? 0x102d9bc6f main + 335 10 dyld 0x202f333a6 start + 1942 According to a [post][1] on the Apple developer forums, hardening was added to CoreFoundation, and this particular message occurs when you attempt to release an object it does not recognize as a valid CF object. (Thank you to @lilyinstarlight for finding this post). When I switched aws-sdk-cpp to link against CoreFoundation instead of CF, the error went away. Somehow both libraries were being used. To prevent dependent packages from linking the wrong CoreFoundation, it would need to be added as a propagated build input. Note that there are other issues related to mixing CF and CoreFoundation frameworks. #264503 fixes an issue with abseil-cpp where it propagates CF, causing issues when using a different SDK version. Mixing versions can also cause crashes with Python when a shared object is loaded that is linked to the “wrong” CoreFoundation. `NIX_COREFOUNDATION_RPATH` is supposed to make sure the right CoreFoundation is being used, but it does not appear to be enough on macOS 14 (presumably due to the hardening). While it is possible to propagate CoreFoundation manually, the cleaner solution is to make it the default. CF remains available as `darwin.swift-corelibs-foundation`. [1]: https://developer.apple.com/forums/thread/739355 --- pkgs/top-level/darwin-packages.nix | 43 ++++++++++++++++++++------------------ 1 file changed, 23 insertions(+), 20 deletions(-) (limited to 'pkgs/top-level/darwin-packages.nix') diff --git a/pkgs/top-level/darwin-packages.nix b/pkgs/top-level/darwin-packages.nix index 435687279c742..2547b0c81cca9 100644 --- a/pkgs/top-level/darwin-packages.nix +++ b/pkgs/top-level/darwin-packages.nix @@ -200,26 +200,29 @@ impure-cmds // appleSourcePackages // chooseLibs // { CoreSymbolication = callPackage ../os-specific/darwin/CoreSymbolication { }; - # TODO: make swift-corefoundation build with apple_sdk_11_0.Libsystem - CF = if useAppleSDKLibs - then - # This attribute (CF) is included in extraBuildInputs in the stdenv. This - # is typically the open source project. When a project refers to - # "CoreFoundation" it has an extra setup hook to force impure system - # CoreFoundation into the link step. - # - # In this branch, we only have a single "CoreFoundation" to choose from. - # To be compatible with the existing convention, we define - # CoreFoundation with the setup hook, and CF as the same package but - # with the setup hook removed. - # - # This may seem unimportant, but without it packages (e.g., bacula) will - # fail with linker errors referring ___CFConstantStringClassReference. - # It's not clear to me why some packages need this extra setup. - lib.overrideDerivation apple_sdk.frameworks.CoreFoundation (drv: { - setupHook = null; - }) - else callPackage ../os-specific/darwin/swift-corelibs/corefoundation.nix { }; + # TODO: Remove the CF hook if a solution to the crashes is not found. + CF = + # CF used to refer to the open source version of CoreFoundation from the Swift + # project. As of macOS 14, the rpath-based approach allowing packages to choose + # which version to use no longer seems to work reliably. Sometimes they works, + # but sometimes they crash with the error (in the system crash logs): + # CF objects must have a non-zero isa. + # See https://developer.apple.com/forums/thread/739355 for more on that error. + # + # In this branch, we only have a single "CoreFoundation" to choose from. + # To be compatible with the existing convention, we define + # CoreFoundation with the setup hook, and CF as the same package but + # with the setup hook removed. + # + # This may seem unimportant, but without it packages (e.g., bacula) will + # fail with linker errors referring ___CFConstantStringClassReference. + # It's not clear to me why some packages need this extra setup. + lib.overrideDerivation apple_sdk.frameworks.CoreFoundation (drv: { + setupHook = null; + }); + + # Formerly the CF attribute. Use this is you need the open source release. + swift-corelibs-foundation = callPackage ../os-specific/darwin/swift-corelibs/corefoundation.nix { }; # As the name says, this is broken, but I don't want to lose it since it's a direction we want to go in # libdispatch-broken = callPackage ../os-specific/darwin/swift-corelibs/libdispatch.nix { }; -- cgit 1.4.1