···22, pkgs
33, newScope
44, darwin
55+, llvmPackages
56, llvmPackages_15
67, overrideCC
78}:
89910let
1111+ swiftLlvmPackages = llvmPackages_15;
1212+1013 self = rec {
11141215 callPackage = newScope self;
···2427 # used in Swift, and applies the same libc overrides as `apple_sdk.stdenv`.
2528 clang = if pkgs.stdenv.isDarwin
2629 then
2727- llvmPackages_15.clang.override rec {
3030+ swiftLlvmPackages.clang.override rec {
2831 libc = apple_sdk.Libsystem;
2932 bintools = pkgs.bintools.override { inherit libc; };
3333+ # Ensure that Swift’s internal clang uses the same libc++ and libc++abi as the
3434+ # default Darwin stdenv. Using the default libc++ avoids issues (such as crashes)
3535+ # that can happen when a Swift application dynamically links different versions
3636+ # of libc++ and libc++abi than libraries it links are using.
3737+ inherit (llvmPackages) libcxx;
3838+ extraPackages = [
3939+ llvmPackages.libcxxabi
4040+ # Use the compiler-rt associated with clang, but use the libc++abi from the stdenv
4141+ # to avoid linking against two different versions (for the same reasons as above).
4242+ (swiftLlvmPackages.compiler-rt.override {
4343+ inherit (llvmPackages) libcxxabi;
4444+ })
4545+ ];
3046 }
3147 else
3232- llvmPackages_15.clang;
4848+ swiftLlvmPackages.clang;
33493450 # Overrides that create a useful environment for swift packages, allowing
3551 # packaging with `swiftPackages.callPackage`. These are similar to
···11{ fetchurl, stdenv, lib
22, enableStatic ? stdenv.hostPlatform.isStatic
33, enableShared ? !stdenv.hostPlatform.isStatic
44+, enableDarwinABICompat ? false
45}:
5667# assert !stdenv.hostPlatform.isLinux || stdenv.hostPlatform != stdenv.buildPlatform; # TODO: improve on cross
···2829 ''
2930 + lib.optionalString (!enableShared) ''
3031 sed -i -e '/preload/d' Makefile.in
3232+ ''
3333+ # The system libiconv is based on libiconv 1.11 with some ABI differences. The following changes
3434+ # build a compatible libiconv on Darwin, allowing it to be sustituted in place of the system one
3535+ # using `install_name_tool`. This removes the need to for a separate, Darwin-specific libiconv
3636+ # derivation and allows Darwin to benefit from upstream updates and fixes.
3737+ + lib.optionalString enableDarwinABICompat ''
3838+ for iconv_h_in in iconv.h.in iconv.h.build.in; do
3939+ substituteInPlace "include/$iconv_h_in" \
4040+ --replace "#define iconv libiconv" "" \
4141+ --replace "#define iconv_close libiconv_close" "" \
4242+ --replace "#define iconv_open libiconv_open" "" \
4343+ --replace "#define iconv_open_into libiconv_open_into" "" \
4444+ --replace "#define iconvctl libiconvctl" "" \
4545+ --replace "#define iconvlist libiconvlist" ""
4646+ done
3147 '';
4848+4949+ # This is hacky, but `libiconv.dylib` needs to reexport `libcharset.dylib` to match the behavior
5050+ # of the system libiconv on Darwin. Trying to do this by modifying the `Makefile` results in an
5151+ # error linking `iconv` because `libcharset.dylib` is not at its final path yet. Avoid the error
5252+ # by building without the reexport then clean and rebuild `libiconv.dylib` with the reexport.
5353+ #
5454+ # For an explanation why `libcharset.dylib` is reexported, see:
5555+ # https://github.com/apple-oss-distributions/libiconv/blob/a167071feb7a83a01b27ec8d238590c14eb6faff/xcodeconfig/libiconv.xcconfig
5656+ postBuild = lib.optionalString enableDarwinABICompat ''
5757+ make clean -C lib
5858+ NIX_CFLAGS_COMPILE+=" -Wl,-reexport-lcharset -L. " make -C lib -j$NIX_BUILD_CORES SHELL=$SHELL
5959+ '';
32603361 configureFlags = [
3462 (lib.enableFeature enableStatic "static")
···6868 ] ++ lib.optionals stdenv.isDarwin [
6969 # https://github.com/NixOS/nixpkgs/issues/209358
7070 "test_scripts_no_environment"
7171+7272+ # This test assumes it is running on macOS with a system shell on the PATH.
7373+ # It is not possible to run it in a nix build using a /nix/store shell.
7474+ # See https://github.com/pypa/hatch/pull/709 for the relevant code.
7575+ "test_populate_default_popen_kwargs_executable"
7176 ];
72777378 meta = with lib; {
···66# run-time) of a package to a consumer that isn't used to thinking so cleverly.
77#
88# The solution is to splice the package sets together as we do below, so every
99-# `callPackage`d expression in fact gets both versions. Each# derivation (and
1010-# each derivation's outputs) consists of the run-time version, augmented with a
1111-# `__spliced.buildHost` field for the build-time version, and `__spliced.hostTarget` field for the
1212-# run-time version.
99+# `callPackage`d expression in fact gets both versions. Each derivation (and
1010+# each derivation's outputs) consists of the run-time version, augmented with
1111+# a `__spliced.buildHost` field for the build-time version, and
1212+# `__spliced.hostTarget` field for the run-time version.
1313#
1414# For performance reasons, rather than uniformally splice in all cases, we only
1515# do so when `pkgs` and `buildPackages` are distinct. The `actuallySplice`