darwin.stdenv: use CoreFoundation instead of CF #265102
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Drop ninja and use a minimal Python to avoid an infinite recursion due to dependencies that depend on configd, which also depends on this.
reckenrode
force-pushed
the
darwin-corefoundation
branch
from
3e5ce60 to
19cc661
Compare
ofborg
bot
added
6.topic: darwin
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 NixOS#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. NixOS#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
reckenrode
force-pushed
the
darwin-corefoundation
branch
from
19cc661 to
daa79a1
Compare
|
you suggest to rebuild darwin stdenv in |
Yes. This is the CoreFoundation change I’ve been discussing in the staging channel on Matrix. @K900 suggested I should probably submit it now if I don’t expect more stdenv rebuilds. |
|
|
|
AFAICT we have 3k regressions on Darwin which can't really be fixed without this, so we basically have to eat the rebuild count. |
|
I’m going to retarget this to staging. While I think it’s an improvement for the maintainability and reliability of Darwin, I’m not seeing where those 3k failures are due to this issue, and not having to rebuild the stdenv is highly preferable right now. |
13 tasks
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
I’m flipping this back out of draft. python3Packages.tokenizers is another example that crashes (along with aws-sdk-cpp and arrow-cpp). The common thread is they all use the AWS SDK and link against both CF and CoreFoundation. While it is possible to fix all the aws-* packages to link CoreFoundation, my concern is that would be kicking the can down the road. In this particular case, only the packages that link other frameworks are linking CoreFoundation. When those are mixed with others that don’t, that’s when things break. |
13 tasks
|
Converting to draft while I figure why retargeting to staging-next is causing an infinite recursion. |
|
Marking this ready. It actually evals. I missed a commit when cherry-picking to confirm locally that there were no eval issues. |
|
Merging to unblock the Darwin staging-next rebuilds. |
reckenrode
added a commit
to reckenrode/nixpkgs
that referenced
this pull request
Nov 16, 2023
Using flat namespaces causes libstdc++ to link CoreFoundation, but that fails after NixOS#265102. Since CoreFoundation is not actually needed, disable flat namespaces to avoid linking it unnecessarily. Disabling flat namespaces matches the behavior of newer versions of libstdc++ (GCC 7+) when building for newer Darwin hosts (10.5+).
13 tasks
ghost
pushed a commit
that referenced
this pull request
Nov 30, 2023
Using flat namespaces causes libstdc++ to link CoreFoundation, but that fails after #265102. Since CoreFoundation is not actually needed, disable flat namespaces to avoid linking it unnecessarily. Disabling flat namespaces matches the behavior of newer versions of libstdc++ (GCC 7+) when building for newer Darwin hosts (10.5+).
github-actions bot
pushed a commit
that referenced
this pull request
Nov 30, 2023
Using flat namespaces causes libstdc++ to link CoreFoundation, but that fails after #265102. Since CoreFoundation is not actually needed, disable flat namespaces to avoid linking it unnecessarily. Disabling flat namespaces matches the behavior of newer versions of libstdc++ (GCC 7+) when building for newer Darwin hosts (10.5+). (cherry picked from commit 647b2db)
reckenrode
added a commit
to reckenrode/nixpkgs
that referenced
this pull request
Jan 28, 2024
As of NixOS#265102, x86_64-darwin no longer uses the open-source CF release. Since there is no longer a need to switch between implementations, and the hook causes problems with cross-compilation (see NixOS#278348), drop the hook and make both darwin.CF an alias for darwin.apple_sdk.frameworks.CoreFoundation.
This was referenced Jan 28, 2024
reckenrode
added a commit
to reckenrode/nixpkgs
that referenced
this pull request
May 31, 2024
As of NixOS#265102, x86_64-darwin no longer uses the open-source CF release. Since there is no longer a need to switch between implementations, and the hook causes problems with cross-compilation (see NixOS#278348), drop the hook and make both darwin.CF an alias for darwin.apple_sdk.frameworks.CoreFoundation.
reckenrode
added a commit
to reckenrode/nixpkgs
that referenced
this pull request
Jun 3, 2024
As of NixOS#265102, x86_64-darwin no longer uses the open-source CF release. Since there is no longer a need to switch between implementations, and the hook causes problems with cross-compilation (see NixOS#278348), drop the hook and make both darwin.CF an alias for darwin.apple_sdk.frameworks.CoreFoundation.
reckenrode
added a commit
to reckenrode/nixpkgs
that referenced
this pull request
Jul 16, 2024
As of NixOS#265102, x86_64-darwin no longer uses the open-source CF release. Since there is no longer a need to switch between implementations, and the hook causes problems with cross-compilation (see NixOS#278348), drop the hook and make both darwin.CF an alias for darwin.apple_sdk.frameworks.CoreFoundation.
reckenrode
added a commit
to reckenrode/nixpkgs
that referenced
this pull request
Jul 26, 2024
Darwin no longer supports switching between CoreFoundation implementations as of NixOS#265102. The setup hook is vestigial and was mostly harmless until NixOS#329526 was necessitated to fix build failures on staging-next NixOS#328673. The correct fix is to remove the hook. It’s not used by the 11.0 or 12.3 SDKs. This makes the 10.12 SDK a bit more like the other SDKs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
This patch switches the CoreFoundation on x86_64-darwin from the open source swift-corelibs-foundation (CF) to the system CoreFoundation. The changes were tested by building the stdenv and Nix, which depends on aws-sdk-cpp.
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
According to a post 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_RPATHis 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 asdarwin.swift-corelibs-foundation.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)