colin/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
daa79a1d2d
nixpkgs/pkgs/stdenv/darwin
History
Randy Eckenrode daa79a1d2d
darwin.stdenv: use CoreFoundation instead of CF 
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
2023-11-02 21:20:55 -04:00
..
default.nix darwin.stdenv: use CoreFoundation instead of CF 2023-11-02 21:20:55 -04:00
fixed-xnu-python3.patch bootstrap-tools: Fix xnu python3 patch 2021-06-05 19:55:38 +02:00
make-bootstrap-tools.nix release.nix: namespace bootstrap tools with triples 2023-10-07 19:38:01 +00:00
patch-bootstrap-tools-next.sh stdenvBootstrapTools: native aarch64-darwin build 2023-02-11 20:11:55 +01:00
portable-libsystem.sh darwin.stdenv: only run install_name_tool on files 2023-07-08 20:49:50 -06:00
README.md darwin.stdenv: refactor stdenv definition 2023-07-02 17:56:24 -04:00
unpack-bootstrap-tools-aarch64.sh stdenv/darwin: Apple Silicon support 2021-05-17 00:27:02 +09:00
unpack-bootstrap-tools.sh darwin/stdenv: tapi stub based bootstrap 2020-12-22 11:43:54 +09:00

README.md

Darwin stdenv design goals

There are two more goals worth calling out explicitly:

  1. The standard environment should build successfully with sandboxing enabled on Darwin. It is fine if a package requires a sandboxProfile to build, but it should not be necessary to disable the sandbox to build the stdenv successfully; and
  2. The output should depend weakly on the bootstrap tools. Historically, Darwin required updating the bootstrap tools prior to updating the version of LLVM used in the standard environment. By not depending on a specific version, the LLVM used on Darwin can be updated simply by bumping the definition of llvmPackages in all-packages.nix.

Updating the stdenv

There are effectively two steps when updating the standard environment:

  1. Update the definition of llvmPackages in all-packages.nix for Darwin to match the value of llvmPackages.latest in all-packages.nix. Timing-wise, this done currently using the spring release of LLVM and once llvmPackages.latest has been updated to match. If the LLVM project has announced a release schedule of patch updates, wait until those are in nixpkgs. Otherwise, the LLVM updates will have to go through staging instead of being merged into master; and
  2. Fix the resulting breakage. Most things break due to additional warnings being turned into errors or additional strictness applied by LLVM. Fixes may come in the form of disabling those new warnings or by fixing the actual source (e.g., with a patch or update upstream). If the fix is trivial (e.g., adding a missing int to an implicit declaration), it is better to fix the problem instead of silencing the warning.