nixpkgs/pkgs/stdenv/darwin/default.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1381 lines
54 KiB
Nix
Raw Normal View History

darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# This file contains the standard build environment for Darwin. It is based on LLVM and is patterned
# after the Linux stdenv. It shares similar goals to the Linux standard environment in that the
# resulting environment should be built purely and not contain any references to it.
#
# For more on the design of the stdenv and updating it, see `README.md`.
#
# See also the top comments of the Linux stdenv `../linux/default.nix` for a good overview of
# the bootstrap process and working with it.
{ lib
2021-06-02 06:25:56 +02:00
, localSystem
, crossSystem
, config
, overlays
, crossOverlays ? [ ]
# Allow passing in bootstrap files directly so we can test the stdenv bootstrap process when changing the bootstrap tools
, bootstrapFiles ? if localSystem.isAarch64 then
import ./bootstrap-files/aarch64-apple-darwin.nix
2020-11-19 09:28:20 +01:00
else
import ./bootstrap-files/x86_64-apple-darwin.nix
}:
assert crossSystem == localSystem;
let
inherit (localSystem) system;
2020-11-19 09:28:20 +01:00
useAppleSDKLibs = localSystem.isAarch64;
commonImpureHostDeps = [
"/bin/sh"
"/usr/lib/libSystem.B.dylib"
"/usr/lib/system/libunc.dylib" # This dependency is "hidden", so our scanning code doesn't pick it up
];
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
isFromNixpkgs = pkg: !(isFromBootstrapFiles pkg);
isFromBootstrapFiles =
pkg: pkg.passthru.isFromBootstrapFiles or false;
isBuiltByNixpkgsCompiler =
pkg: isFromNixpkgs pkg && isFromNixpkgs pkg.stdenv.cc.cc;
isBuiltByBootstrapFilesCompiler =
pkg: isFromNixpkgs pkg && isFromBootstrapFiles pkg.stdenv.cc.cc;
commonPreHook = ''
export NIX_ENFORCE_NO_NATIVE=''${NIX_ENFORCE_NO_NATIVE-1}
export NIX_ENFORCE_PURITY=''${NIX_ENFORCE_PURITY-1}
export NIX_IGNORE_LD_THROUGH_GCC=1
unset SDKROOT
'';
bootstrapTools = derivation ({
inherit system;
2021-06-02 06:25:56 +02:00
name = "bootstrap-tools";
builder = "${bootstrapFiles.unpack}/bin/bash";
args = [
"${bootstrapFiles.unpack}/bootstrap-tools-unpack.sh"
bootstrapFiles.bootstrapTools
];
PATH = lib.makeBinPath [
(placeholder "out")
bootstrapFiles.unpack
];
__impureHostDeps = commonImpureHostDeps;
} // lib.optionalAttrs config.contentAddressedByDefault {
__contentAddressed = true;
outputHashAlgo = "sha256";
outputHashMode = "recursive";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
}) // { passthru.isFromBootstrapFiles = true; };
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
stageFun = prevStage:
{ name, overrides ? (self: super: { }), extraNativeBuildInputs ? [ ], extraPreHook ? "" }:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
let
cc = if prevStage.llvmPackages.clang-unwrapped == null
then null else
lib.makeOverridable (import ../../build-support/cc-wrapper) {
name = "${name}-clang-wrapper";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
nativeTools = false;
nativeLibc = false;
expand-response-params = lib.optionalString
(prevStage.stdenv.hasCC or false && prevStage.stdenv.cc != "/dev/null")
prevStage.expand-response-params;
2021-06-02 06:25:56 +02:00
extraPackages = [
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
prevStage.llvmPackages.compiler-rt
];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraBuildCommands =
let
inherit (prevStage.llvmPackages) clang-unwrapped compiler-rt release_version;
in
''
function clangResourceRootIncludePath() {
clangLib="$1/lib/clang"
if (( $(ls "$clangLib" | wc -l) > 1 )); then
echo "Multiple LLVM versions were found at "$clangLib", but there must only be one used when building the stdenv." >&2
exit 1
fi
echo "$clangLib/$(ls -1 "$clangLib")/include"
}
rsrc="$out/resource-root"
mkdir "$rsrc"
ln -s "$(clangResourceRootIncludePath "${clang-unwrapped.lib}")" "$rsrc"
ln -s "${compiler-rt.out}/lib" "$rsrc/lib"
ln -s "${compiler-rt.out}/share" "$rsrc/share"
echo "-resource-dir=$rsrc" >> $out/nix-support/cc-cflags
'';
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
cc = prevStage.llvmPackages.clang-unwrapped;
bintools = prevStage.darwin.binutils;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
isClang = true;
libc = prevStage.darwin.Libsystem;
inherit (prevStage.llvmPackages) libcxx;
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit lib;
inherit (prevStage) coreutils gnugrep;
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
stdenvNoCC = prevStage.ccWrapperStdenv;
runtimeShell = prevStage.ccWrapperStdenv.shell;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
};
bash = prevStage.bash or bootstrapTools;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
thisStdenv = import ../generic {
name = "${name}-stdenv-darwin";
buildPlatform = localSystem;
hostPlatform = localSystem;
targetPlatform = localSystem;
inherit config;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraBuildInputs = [ prevStage.darwin.CF ];
extraNativeBuildInputs = extraNativeBuildInputs
++ [ prevStage.darwin.apple_sdk.sdkRoot ];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
preHook = lib.optionalString (!isBuiltByNixpkgsCompiler bash) ''
# Don't patch #!/interpreter because it leads to retained
# dependencies on the bootstrapTools in the final stdenv.
dontPatchShebangs=1
'' + ''
${commonPreHook}
${extraPreHook}
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
'' + lib.optionalString (prevStage.darwin ? locale) ''
export PATH_LOCALE=${prevStage.darwin.locale}/share/locale
'';
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
shell = bash + "/bin/bash";
initialPath = [ bash bootstrapTools ];
fetchurlBoot = import ../../build-support/fetchurl {
inherit lib;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
stdenvNoCC = prevStage.ccWrapperStdenv or thisStdenv;
curl = bootstrapTools;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit cc;
# The stdenvs themselves don't use mkDerivation, so I need to specify this here
__stdenvImpureHostDeps = commonImpureHostDeps;
__extraImpureHostDeps = commonImpureHostDeps;
# Using the bootstrap tools curl for fetchers allows the stdenv bootstrap to avoid
# having a dependency on curl, allowing curl to be updated without triggering a
# new stdenv bootstrap on Darwin.
2021-06-02 06:25:56 +02:00
overrides = self: super: (overrides self super) // {
fetchurl = thisStdenv.fetchurlBoot;
fetchpatch = super.fetchpatch.override { inherit (self) fetchurl; };
fetchgit = super.fetchgit.override {
git = super.git.override { curl = bootstrapTools; };
};
fetchzip = super.fetchzip.override { inherit (self) fetchurl; };
};
};
2021-06-02 06:25:56 +02:00
in
{
inherit config overlays;
stdenv = thisStdenv;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
in
assert bootstrapTools.passthru.isFromBootstrapFiles or false; # sanity check
[
({}: {
__raw = true;
coreutils = null;
gnugrep = null;
pbzx = null;
cpio = null;
darwin = {
apple_sdk.sdkRoot = null;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
binutils = null;
binutils-unwrapped = null;
cctools = null;
print-reexports = null;
rewrite-tbd = null;
sigtool = null;
CF = null;
Libsystem = null;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
llvmPackages = {
clang-unwrapped = null;
libllvm = null;
libcxx = null;
compiler-rt = null;
};
})
# Create a stage with the bootstrap tools. This will be used to build the subsequent stages and
# build up the standard environment.
#
# Note: Each stage depends only on the the packages in `prevStage`. If a package is not to be
# rebuilt, it should be passed through by inheriting it.
(prevStage: stageFun prevStage {
name = "bootstrap-stage0";
overrides = self: super: {
# We thread stage0's stdenv through under this name so downstream stages
# can use it for wrapping gcc too. This way, downstream stages don't need
# to refer to this stage directly, which violates the principle that each
# stage should only access the stage that came before it.
ccWrapperStdenv = self.stdenv;
bash = bootstrapTools;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
coreutils = bootstrapTools;
cpio = bootstrapTools;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
gnugrep = bootstrapTools;
pbzx = bootstrapTools;
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 01:56:50 +01:00
darwin = super.darwin.overrideScope (selfDarwin: superDarwin: {
# Prevent CF from being propagated to the initial stdenv. Packages that require it
# will have to manually add it to their build inputs.
CF = null;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
binutils-unwrapped = bootstrapTools // {
version = "boot";
};
2020-11-19 09:28:20 +01:00
binutils = super.wrapBintoolsWith {
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
name = "bootstrap-stage0-binutils-wrapper";
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
nativeTools = false;
nativeLibc = false;
2020-11-19 09:28:20 +01:00
expand-response-params = "";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libc = selfDarwin.Libsystem;
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit lib;
inherit (self) stdenvNoCC coreutils gnugrep;
runtimeShell = self.stdenvNoCC.shell;
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
bintools = selfDarwin.binutils-unwrapped;
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit (selfDarwin) postLinkSignHook signingUtils;
};
2020-11-19 09:28:20 +01:00
cctools = bootstrapTools // {
2020-11-19 09:28:20 +01:00
targetPrefix = "";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
version = "boot";
man = bootstrapTools;
2020-11-19 09:28:20 +01:00
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
locale = self.stdenv.mkDerivation {
name = "bootstrap-stage0-locale";
buildCommand = ''
mkdir -p $out/share/locale
'';
};
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
print-reexports = bootstrapTools;
rewrite-tbd = bootstrapTools;
sigtool = bootstrapTools;
2020-11-19 09:28:20 +01:00
} // lib.optionalAttrs (! useAppleSDKLibs) {
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
Libsystem = self.stdenv.mkDerivation {
name = "bootstrap-stage0-Libsystem";
buildCommand = ''
mkdir -p $out
cp -r ${selfDarwin.darwin-stubs}/usr/lib $out/lib
chmod -R +w $out/lib
substituteInPlace $out/lib/libSystem.B.tbd --replace /usr/lib/system $out/lib/system
ln -s libSystem.B.tbd $out/lib/libSystem.tbd
for name in c dbm dl info m mx poll proc pthread rpcsvc util gcc_s.10.4 gcc_s.10.5; do
ln -s libSystem.tbd $out/lib/lib$name.tbd
done
ln -s ${bootstrapTools}/lib/*.o $out/lib
ln -s ${bootstrapTools}/lib/libresolv.9.dylib $out/lib
ln -s libresolv.9.dylib $out/lib/libresolv.dylib
ln -s ${bootstrapTools}/include-Libsystem $out/include
'';
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
passthru.isFromBootstrapFiles = true;
};
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
llvmPackages = super.llvmPackages // (
let
tools = super.llvmPackages.tools.extend (selfTools: _: {
libclang = self.stdenv.mkDerivation {
name = "bootstrap-stage0-clang";
version = "boot";
outputs = [ "out" "lib" ];
buildCommand = ''
mkdir -p $out/lib
ln -s $out $lib
ln -s ${bootstrapTools}/bin $out/bin
ln -s ${bootstrapTools}/lib/clang $out/lib
ln -s ${bootstrapTools}/include $out
'';
passthru = {
isFromBootstrapFiles = true;
hardeningUnsupportedFlags = [ "fortify3" "zerocallusedregs" ];
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
};
clang-unwrapped = selfTools.libclang;
libllvm = self.stdenv.mkDerivation {
name = "bootstrap-stage0-llvm";
outputs = [ "out" "lib" ];
buildCommand = ''
mkdir -p $out/bin $out/lib
ln -s $out $lib
ln -s ${bootstrapTools}/bin/strip $out/bin/llvm-strip
ln -s ${bootstrapTools}/lib/libLLVM* $out/lib
'';
passthru.isFromBootstrapFiles = true;
};
llvm = selfTools.libllvm;
});
libraries = super.llvmPackages.libraries.extend (_: _: {
libcxx = self.stdenv.mkDerivation {
name = "bootstrap-stage0-libcxx";
buildCommand = ''
mkdir -p $out/lib $out/include
ln -s ${bootstrapTools}/lib/libc++.dylib $out/lib
ln -s ${bootstrapTools}/include/c++ $out/include
'';
passthru = {
isLLVM = true;
isFromBootstrapFiles = true;
};
};
compiler-rt = self.stdenv.mkDerivation {
name = "bootstrap-stage0-compiler-rt";
buildCommand = ''
mkdir -p $out/lib $out/share
ln -s ${bootstrapTools}/lib/libclang_rt* $out/lib
ln -s ${bootstrapTools}/lib/darwin $out/lib
'';
passthru.isFromBootstrapFiles = true;
};
});
in
{ inherit tools libraries; } // tools // libraries
);
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# The bootstrap tools may use `strip` from cctools, so use a compatible set of flags until LLVM
# is rebuilt, and darwin.binutils can use its implementation instead.
extraPreHook = ''
stripAllFlags=" " # the cctools "strip" command doesn't know "-s"
stripDebugFlags="-S" # the cctools "strip" command does something odd with "-p"
'';
})
# This stage is primarily responsible for building the linker and setting up versions of
# certain dependencies needed by the rest of the build process. It is necessary to rebuild the
# linker because the `compiler-rt` build process checks the version and attempts to manually
# run `codesign` if it detects a version of `ld64` it considers too old. If that happens, the
# build process will fail for a few different reasons:
# - sigtool is too old and does not accept the `--sign` argument;
# - sigtool is new enough to accept the `--sign` argument, but it aborts when it is invoked on a
# binary that is already signed; or
# - compiler-rt attempts to invoke `codesign` on x86_64-darwin, but `sigtool` is not currently
# part of the x86_64-darwin bootstrap tools.
#
# This stage also builds CF and Libsystem to simplify assertions and assumptions for later by
# making sure both packages are present on x86_64-darwin and aarch64-darwin.
(prevStage:
# previous stage0 stdenv:
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 01:56:50 +01:00
assert lib.all isFromBootstrapFiles (
with prevStage; [ bash coreutils cpio gnugrep ] ++ lib.optionals useAppleSDKLibs [ pbzx ]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert lib.all isFromBootstrapFiles (with prevStage.darwin; [
binutils-unwrapped cctools print-reexports rewrite-tbd sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isFromBootstrapFiles (with prevStage.darwin; [ Libsystem ]);
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ Libsystem ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd xnu ]);
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 01:56:50 +01:00
assert (with prevStage.darwin; (! useAppleSDKLibs) -> CF == null);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert lib.all isFromBootstrapFiles (with prevStage.llvmPackages; [
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
clang-unwrapped libclang libllvm llvm compiler-rt libcxx
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
stageFun prevStage {
name = "bootstrap-stage1";
overrides = self: super: {
inherit (prevStage) ccWrapperStdenv
coreutils gnugrep;
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 01:56:50 +01:00
# Use this stages CF to build CMake. Its required but cant be included in the stdenv.
cmake = self.cmakeMinimal;
cmakeMinimal = super.cmakeMinimal.overrideAttrs (old: {
buildInputs = old.buildInputs ++ [ self.darwin.CF ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Disable tests because they use dejagnu, which fails to run.
libffi = super.libffi.override { doCheck = false; };
# Avoid pulling in a full python and its extra dependencies for the llvm/clang builds.
libxml2 = super.libxml2.override { pythonSupport = false; };
ninja = super.ninja.override { buildDocs = false; };
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 01:56:50 +01:00
# Use this stages CF to build Python. Its required but cant be included in the stdenv.
python3 = self.python3Minimal;
python3Minimal = super.python3Minimal.overrideAttrs (old: {
buildInputs = old.buildInputs ++ [ self.darwin.CF ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
darwin = super.darwin.overrideScope (selfDarwin: superDarwin: {
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
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 01:56:50 +01:00
# Use this stages CF to build configd. Its required but cant be included in the stdenv.
configd = superDarwin.configd.overrideAttrs (old: {
buildInputs = old.buildInputs or [ ] ++ [ self.darwin.CF ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
signingUtils = prevStage.darwin.signingUtils.override {
inherit (selfDarwin) sigtool;
};
2023-07-08 11:44:20 +02:00
postLinkSignHook = prevStage.darwin.postLinkSignHook.override {
inherit (selfDarwin) sigtool;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
binutils = superDarwin.binutils.override {
inherit (self) coreutils;
inherit (selfDarwin) postLinkSignHook signingUtils;
bintools = selfDarwin.binutils-unwrapped;
libc = selfDarwin.Libsystem;
# TODO(@sternenseemann): can this be removed?
runtimeShell = "${bootstrapTools}/bin/bash";
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
binutils-unwrapped = superDarwin.binutils-unwrapped.override {
inherit (selfDarwin) cctools;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
cctools = selfDarwin.cctools-port;
});
llvmPackages = super.llvmPackages // (
let
tools = super.llvmPackages.tools.extend (_: _: {
inherit (prevStage.llvmPackages) clang-unwrapped libclang libllvm llvm;
});
libraries = super.llvmPackages.libraries.extend (_: _: {
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
inherit (prevStage.llvmPackages) compiler-rt libcxx;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit tools libraries; inherit (prevStage.llvmPackages) release_version; } // tools // libraries
);
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
# The bootstrap tools may use `strip` from cctools, so use a compatible set of flags until LLVM
# is rebuilt, and darwin.binutils can use its implementation instead.
extraPreHook = ''
stripAllFlags=" " # the cctools "strip" command doesn't know "-s"
stripDebugFlags="-S" # the cctools "strip" command does something odd with "-p"
# Dont assume the ld64 in bootstrap tools supports response files. Only recent versions do.
export NIX_LD_USE_RESPONSE_FILE=0
'';
})
# Build cctools, Python, and sysctl for use by LLVMs check phase. They must be built in
# their stage to prevent infinite recursions and to make sure the stdenv used to build
# LLVM has the newly built cctools instead of the one from the bootstrap tools.
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
(prevStage:
# previous stage1 stdenv:
assert lib.all isFromBootstrapFiles (with prevStage; [ coreutils gnugrep ]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
autoconf automake bash binutils-unwrapped bison brotli cmake cpio cyrus_sasl db
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
ed expat flex gettext gmp groff icu libedit libffi libiconv libidn2 libkrb5 libssh2
libtool libunistring libxml2 m4 ncurses nghttp2 ninja openldap openssh openssl
patchutils pbzx perl pkg-config.pkg-config python3 python3Minimal scons serf sqlite
subversion texinfo unzip which xz zlib zstd
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [
binutils-unwrapped cctools locale libtapi print-reexports rewrite-tbd sigtool
]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ Libsystem configd ]);
assert (! useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF Libsystem libobjc]);
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd xnu ]);
assert lib.all isFromBootstrapFiles (with prevStage.llvmPackages; [
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
clang-unwrapped libclang libllvm llvm compiler-rt libcxx
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.getVersion prevStage.stdenv.cc.bintools.bintools == "boot";
stageFun prevStage {
name = "bootstrap-stage1-sysctl";
overrides = self: super: {
inherit (prevStage) ccWrapperStdenv
autoconf automake bash binutils binutils-unwrapped bison brotli cmake cmakeMinimal
coreutils cpio cyrus_sasl db ed expat flex gettext gmp gnugrep groff icu
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libedit libffi libiconv libidn2 libkrb5 libssh2 libtool libunistring libxml2 m4
ncurses nghttp2 ninja openldap openssh openssl patchutils pbzx perl pkg-config
python3Minimal scons sed serf sharutils sqlite subversion texinfo unzip which xz
zlib zstd;
# Support for the SystemConfiguration framework is required to run the LLVM tests, but trying
# to override python3Minimal does not appear to work.
python3 = (super.python3.override {
inherit (self) libffi;
inherit (self.darwin) configd;
openssl = null;
readline = null;
ncurses = null;
gdbm = null;
sqlite = null;
tzdata = null;
stripConfig = true;
stripIdlelib = true;
stripTests = true;
stripTkinter = true;
rebuildBytecode = false;
stripBytecode = true;
includeSiteCustomize = false;
enableOptimizations = false;
enableLTO = false;
mimetypesSupport = false;
}).overrideAttrs (_: { pname = "python3-minimal-scproxy"; });
darwin = super.darwin.overrideScope (_: superDarwin: {
inherit (prevStage.darwin)
CF sdkRoot Libsystem binutils-unwrapped cctools cctools-port configd darwin-stubs dyld
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
launchd libclosure libdispatch libobjc locale objc4 postLinkSignHook
print-reexports rewrite-tbd signingUtils sigtool;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
llvmPackages = super.llvmPackages // (
let
tools = super.llvmPackages.tools.extend (_: _: {
inherit (prevStage.llvmPackages) clang-unwrapped libclang libllvm llvm;
clang = prevStage.stdenv.cc;
});
libraries = super.llvmPackages.libraries.extend (_: _: {
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
inherit (prevStage.llvmPackages) compiler-rt libcxx;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit tools libraries; inherit (prevStage.llvmPackages) release_version; } // tools // libraries
);
};
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
# Until LLVM is rebuilt, assume `strip` is the one from cctools.
extraPreHook = ''
stripAllFlags=" " # the cctools "strip" command doesn't know "-s"
stripDebugFlags="-S" # the cctools "strip" command does something odd with "-p"
'';
})
# First rebuild of LLVM. While this LLVM is linked to a bunch of junk from the bootstrap tools,
# the libc++ and libc++abi it produces are not. The compiler will be rebuilt in a later stage,
# but those libraries will be used in the final stdenv.
#
# Rebuild coreutils and gnugrep to avoid unwanted references to the bootstrap tools on `PATH`.
(prevStage:
# previous stage-sysctl stdenv:
assert lib.all isFromBootstrapFiles (with prevStage; [ coreutils gnugrep ]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
autoconf automake bash binutils-unwrapped bison brotli cmake cpio cyrus_sasl db
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
ed expat flex gettext gmp groff icu libedit libffi libiconv libidn2 libkrb5 libssh2
libtool libunistring libxml2 m4 ncurses nghttp2 ninja openldap openssh openssl
patchutils pbzx perl pkg-config.pkg-config python3 python3Minimal scons serf sqlite
subversion sysctl.provider texinfo unzip which xz zlib zstd
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [
binutils-unwrapped cctools locale libtapi print-reexports rewrite-tbd sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ Libsystem configd ]);
assert (! useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF Libsystem libobjc ]);
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd xnu ]);
assert lib.all isFromBootstrapFiles (with prevStage.llvmPackages; [
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
clang-unwrapped libclang libllvm llvm compiler-rt libcxx
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.getVersion prevStage.stdenv.cc.bintools.bintools == lib.getVersion prevStage.darwin.cctools-port;
stageFun prevStage {
name = "bootstrap-stage-xclang";
overrides = self: super: {
inherit (prevStage) ccWrapperStdenv
autoconf automake bash binutils binutils-unwrapped bison brotli cmake cmakeMinimal
cpio cyrus_sasl db ed expat flex gettext gmp groff icu libedit libffi libiconv
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libidn2 libkrb5 libssh2 libtool libunistring libxml2 m4 ncurses nghttp2 ninja
openldap openssh openssl patchutils pbzx perl pkg-config python3 python3Minimal
scons sed serf sharutils sqlite subversion sysctl texinfo unzip which xz zlib zstd;
# Switch from cctools-port to cctools-llvm now that LLVM has been built.
darwin = super.darwin.overrideScope (_: superDarwin: {
inherit (prevStage.darwin)
CF Libsystem configd darwin-stubs dyld launchd libclosure libdispatch libobjc
locale objc4 postLinkSignHook print-reexports rewrite-tbd signingUtils sigtool;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Avoid building unnecessary Python dependencies due to building LLVM manpages.
cctools-llvm = superDarwin.cctools-llvm.override { enableManpages = false; };
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
llvmPackages = super.llvmPackages // (
let
llvmMajor = lib.versions.major super.llvmPackages.release_version;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# libc++, and libc++abi do not need CoreFoundation. Avoid propagating the CF from prior
# stages to the final stdenv via rpath by dropping it from `extraBuildInputs`.
stdenvNoCF = self.stdenv.override {
extraBuildInputs = [ ];
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libcxxBootstrapStdenv = self.overrideCC stdenvNoCF (self.llvmPackages.clangNoCompilerRtWithLibc.override {
nixSupport.cc-cflags = [ "-nostdlib" ];
nixSupport.cc-ldflags = [ "-lSystem" ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libraries = super.llvmPackages.libraries.extend (selfLib: superLib: {
compiler-rt = null;
libcxx = superLib.libcxx.override ({
stdenv = libcxxBootstrapStdenv;
2021-06-02 06:25:56 +02:00
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit libraries; } // libraries
);
};
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
extraPreHook = ''
stripAllFlags=" " # the cctools "strip" command doesn't know "-s"
stripDebugFlags="-S" # the cctools "strip" command does something odd with "-p"
'';
})
# This stage rebuilds Libsystem. It also rebuilds bash, which will be needed in later stages
# to use in patched shebangs (e.g., to make sure `icu-config` uses bash from nixpkgs).
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
(prevStage:
# previous stage-xclang stdenv:
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
autoconf automake bash binutils-unwrapped bison cmake cmakeMinimal coreutils cpio
cyrus_sasl db ed expat flex gettext gmp gnugrep groff icu libedit libtool m4 ninja
openbsm openldap openpam openssh patchutils pbzx perl pkg-config.pkg-config python3
python3Minimal scons serf sqlite subversion sysctl.provider texinfo unzip which xz
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
brotli libffi libiconv libidn2 libkrb5 libssh2 libunistring libxml2 ncurses
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
nghttp2 openssl zlib zstd
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [
binutils-unwrapped cctools locale libtapi print-reexports rewrite-tbd sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ Libsystem configd ]);
assert (! useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF Libsystem libobjc ]);
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd libclosure libdispatch xnu ]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.llvmPackages; [
clang-unwrapped libclang libllvm llvm
]);
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.llvmPackages; [ libcxx ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert prevStage.llvmPackages.compiler-rt == null;
assert lib.getVersion prevStage.stdenv.cc.bintools.bintools == lib.getVersion prevStage.darwin.cctools-port;
stageFun prevStage {
name = "bootstrap-stage2-Libsystem";
overrides = self: super: {
inherit (prevStage) ccWrapperStdenv
autoconf automake binutils-unwrapped bison brotli cmake cmakeMinimal coreutils
cpio cyrus_sasl db ed expat flex gettext gmp gnugrep groff icu libedit libffi
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libiconv libidn2 libkrb5 libssh2 libtool libunistring libxml2 m4 ncurses nghttp2
ninja openbsm openldap openpam openssh openssl patchutils pbzx perl pkg-config
python3 python3Minimal scons serf sqlite subversion sysctl texinfo unzip which xz
zlib zstd;
2020-11-19 09:28:20 +01:00
# Bash must be linked against the system CoreFoundation instead of the open-source one.
# Otherwise, there will be a dependency cycle: bash -> CF -> icu -> bash (for icu^dev).
bash = super.bash.overrideAttrs (super: {
buildInputs = super.buildInputs ++ [ self.darwin.apple_sdk.frameworks.CoreFoundation ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
darwin = super.darwin.overrideScope (selfDarwin: superDarwin: {
inherit (prevStage.darwin)
CF binutils-unwrapped cctools configd darwin-stubs launchd libobjc libtapi locale
objc4 print-reexports rewrite-tbd signingUtils sigtool;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
llvmPackages = super.llvmPackages // (
let
tools = super.llvmPackages.tools.extend (_: _: {
inherit (prevStage.llvmPackages) clang-unwrapped clangNoCompilerRtWithLibc libclang libllvm llvm;
});
libraries = super.llvmPackages.libraries.extend (selfLib: superLib: {
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
inherit (prevStage.llvmPackages) compiler-rt libcxx;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit tools libraries; inherit (prevStage.llvmPackages) release_version; } // tools // libraries
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Dont link anything in this stage against CF to prevent propagating CF from prior stages to
# the final stdenv, which happens because of the rpath hook.
stdenv =
let
stdenvNoCF = super.stdenv.override {
extraBuildInputs = [ ];
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
in
self.overrideCC stdenvNoCF (self.llvmPackages.clangNoCompilerRtWithLibc.override {
inherit (self.llvmPackages) libcxx;
});
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
})
# This stage rebuilds CF, compiler-rt, and the sdkRoot derivation.
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
#
# CF requires:
# - aarch64-darwin: libobjc (due to being apple_sdk.frameworks.CoreFoundation instead of swift-corefoundation)
# - x86_64-darwin: libiconv libxml2 icu zlib
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
(prevStage:
# previous stage2-Libsystem stdenv:
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
autoconf automake binutils-unwrapped bison brotli cmake cmakeMinimal coreutils
cpio cyrus_sasl db ed expat flex gettext gmp gnugrep groff icu libedit libidn2
libkrb5 libssh2 libtool libunistring m4 nghttp2 ninja openbsm openldap openpam openssh
openssl patchutils pbzx perl pkg-config.pkg-config python3 python3Minimal scons serf
sqlite subversion sysctl.provider texinfo unzip which xz zstd
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage; [ bash ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
libffi libiconv libxml2 ncurses zlib zstd
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [
binutils-unwrapped cctools locale libtapi print-reexports rewrite-tbd sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ configd ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [ Libsystem ]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF Libsystem libobjc ]);
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd libclosure libdispatch xnu ]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.llvmPackages; [
clang-unwrapped libclang libllvm llvm
]);
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.llvmPackages; [ libcxx ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert prevStage.llvmPackages.compiler-rt == null;
assert lib.getVersion prevStage.stdenv.cc.bintools.bintools == lib.getVersion prevStage.darwin.cctools-llvm;
stageFun prevStage {
name = "bootstrap-stage2-CF";
overrides = self: super: {
inherit (prevStage) ccWrapperStdenv
autoconf automake bash bison brotli cmake cmakeMinimal coreutils cpio
cyrus_sasl db ed expat flex gettext gmp gnugrep groff libedit libidn2 libkrb5
libssh2 libtool libunistring m4 ncurses nghttp2 ninja openbsm openldap openpam
openssh openssl patchutils pbzx perl pkg-config python3 python3Minimal scons serf
sqlite subversion sysctl texinfo unzip which xz zstd;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Avoid pulling in a full python and its extra dependencies for the llvm/clang builds.
libxml2 = super.libxml2.override { pythonSupport = false; };
darwin = super.darwin.overrideScope (selfDarwin: superDarwin: {
inherit (prevStage.darwin)
Libsystem configd darwin-stubs launchd locale print-reexports rewrite-tbd
signingUtils sigtool;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Rewrap binutils so it uses the rebuilt Libsystem.
binutils = superDarwin.binutils.override {
inherit (prevStage) expand-response-params;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libc = selfDarwin.Libsystem;
} // {
passthru = { inherit (prevStage.bintools.passthru) isFromBootstrapFiles; };
};
# Avoid building unnecessary Python dependencies due to building LLVM manpages.
cctools-llvm = superDarwin.cctools-llvm.override { enableManpages = false; };
});
llvmPackages = super.llvmPackages // (
let
tools = super.llvmPackages.tools.extend (_: _: {
inherit (prevStage.llvmPackages) clang-unwrapped clangNoCompilerRtWithLibc libclang libllvm llvm;
clang = prevStage.stdenv.cc;
});
libraries = super.llvmPackages.libraries.extend (selfLib: superLib: {
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
inherit (prevStage.llvmPackages) libcxx;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Make sure compiler-rt is linked against the CF from this stage, which can be
# propagated to the final stdenv. CF is required by ASAN.
compiler-rt = superLib.compiler-rt.override ({
inherit (self.llvmPackages) libllvm;
stdenv = self.stdenv.override {
extraBuildInputs = [ self.darwin.CF ];
2021-06-02 06:25:56 +02:00
};
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit tools libraries; inherit (prevStage.llvmPackages) release_version; } // tools // libraries
);
2021-06-02 06:25:56 +02:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Dont link anything in this stage against CF to prevent propagating CF from prior stages to
# the final stdenv, which happens because of the rpath hook. Also dont use a stdenv with
# compiler-rt because it needs to be built in this stage.
stdenv =
let
stdenvNoCF = super.stdenv.override {
extraBuildInputs = [ ];
};
in
self.overrideCC stdenvNoCF (self.llvmPackages.clangNoCompilerRtWithLibc.override {
inherit (self.llvmPackages) libcxx;
# Make sure the stdenv is using the Libsystem that will be propagated to the final stdenv.
libc = self.darwin.Libsystem;
bintools = self.llvmPackages.clangNoCompilerRtWithLibc.bintools.override {
libc = self.darwin.Libsystem;
};
});
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
})
# Rebuild LLVM with LLVM. This stage also rebuilds certain dependencies needed by LLVM.
#
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
# LLVM requires: libcxx libffi libiconv libxml2 ncurses zlib
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
(prevStage:
# previous stage2-CF stdenv:
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
autoconf automake bison brotli cmake cmakeMinimal coreutils cpio cyrus_sasl
db ed expat flex gettext gmp gnugrep groff libedit libidn2 libkrb5 libssh2 libtool
libunistring m4 ncurses nghttp2 ninja openbsm openldap openpam openssh openssl
patchutils pbzx perl pkg-config.pkg-config python3 python3Minimal scons serf sqlite
subversion sysctl.provider texinfo unzip which xz zstd
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage; [
bash binutils-unwrapped icu libffi libiconv libxml2 zlib
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [
locale print-reexports rewrite-tbd sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [
binutils-unwrapped cctools libtapi
]);
assert (! useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ configd ]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [ Libsystem ]);
assert (! useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF Libsystem libobjc ]);
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd libclosure libdispatch xnu ]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.llvmPackages; [
clang-unwrapped libclang libllvm llvm
]);
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.llvmPackages; [ libcxx ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert lib.getVersion prevStage.stdenv.cc.bintools.bintools == lib.getVersion prevStage.darwin.cctools-llvm;
stageFun prevStage {
name = "bootstrap-stage3";
overrides = self: super: {
inherit (prevStage) ccWrapperStdenv
autoconf automake bash binutils binutils-unwrapped bison brotli cmake cmakeMinimal
coreutils cpio cyrus_sasl db ed expat flex gettext gmp gnugrep groff libedit
libidn2 libkrb5 libssh2 libtool libunistring m4 nghttp2 ninja openbsm openldap
openpam openssh openssl patchutils pbzx perl pkg-config python3 python3Minimal scons
sed serf sharutils sqlite subversion sysctl texinfo unzip which xz zstd
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# CF dependencies - dont rebuild them.
icu libiconv libxml2 zlib;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Disable tests because they use dejagnu, which fails to run.
libffi = super.libffi.override { doCheck = false; };
2021-06-02 06:25:56 +02:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
darwin = super.darwin.overrideScope (selfDarwin: superDarwin: {
inherit (prevStage.darwin)
CF Libsystem binutils binutils-unwrapped cctools cctools-llvm cctools-port configd
darwin-stubs dyld launchd libclosure libdispatch libobjc libtapi locale objc4
postLinkSignHook print-reexports rewrite-tbd signingUtils sigtool;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
llvmPackages = super.llvmPackages // (
let
libraries = super.llvmPackages.libraries.extend (_: _: {
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
inherit (prevStage.llvmPackages) compiler-rt libcxx;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit libraries; } // libraries
);
};
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
})
# Construct a standard environment with the new clang. Also use the new compiler to rebuild
# everything that will be part of the final stdenv and isnt required by it, CF, or Libsystem.
(prevStage:
# previous stage3 stdenv:
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
autoconf automake bison brotli cmake cmakeMinimal coreutils cpio cyrus_sasl
db ed expat flex gettext gmp gnugrep groff libedit libidn2 libkrb5 libssh2 libtool
libunistring m4 nghttp2 ninja openbsm openldap openpam openssh openssl patchutils pbzx
perl pkg-config.pkg-config python3 python3Minimal scons serf sqlite subversion
sysctl.provider texinfo unzip which xz zstd
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage; [
bash binutils-unwrapped icu libffi libiconv libxml2 zlib
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [
locale print-reexports rewrite-tbd sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [
binutils-unwrapped cctools libtapi
]);
assert (! useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ configd ]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [ Libsystem ]);
assert (! useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF Libsystem libobjc ]);
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd libclosure libdispatch xnu ]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.llvmPackages; [
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
clang-unwrapped libclang libllvm llvm compiler-rt libcxx
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.getVersion prevStage.stdenv.cc.bintools.bintools == lib.getVersion prevStage.darwin.cctools-llvm;
stageFun prevStage {
name = "bootstrap-stage4";
overrides = self: super: {
inherit (prevStage) ccWrapperStdenv
autoconf automake bash bison cmake cmakeMinimal cyrus_sasl db expat flex groff
libedit libtool m4 ninja openldap openssh patchutils perl pkg-config python3 scons
serf sqlite subversion sysctl texinfo unzip which
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# CF dependencies - dont rebuild them.
icu
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# LLVM dependencies - dont rebuild them.
libffi libiconv libxml2 ncurses zlib;
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
darwin = super.darwin.overrideScope (selfDarwin: superDarwin: {
inherit (prevStage.darwin) dyld CF Libsystem darwin-stubs
# CF dependencies - dont rebuild them.
libobjc objc4;
2021-06-02 06:25:56 +02:00
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
signingUtils = superDarwin.signingUtils.override {
inherit (selfDarwin) sigtool;
};
2021-06-02 06:25:56 +02:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
binutils = superDarwin.binutils.override {
inherit (prevStage) expand-response-params;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
bintools = selfDarwin.binutils-unwrapped;
libc = selfDarwin.Libsystem;
};
# cctools needs to build the LLVM man pages, which requires sphinx. Sphinx
# has hatch-vcs as a transitive dependency, which pulls in git (and curl).
# Disabling the tests for hatch-vcs allows the stdenv bootstrap to avoid having
# any dependency on curl other than the one provided in the bootstrap tools.
cctools-llvm = superDarwin.cctools-llvm.override (old: {
llvmPackages =
let
tools = old.llvmPackages.tools.extend (_: superTools: {
llvm-manpages = superTools.llvm-manpages.override {
python3Packages = prevStage.python3Packages.overrideScope (_: superPython: {
hatch-vcs = (superPython.hatch-vcs.override {
git = null;
pytestCheckHook = null;
});
});
};
});
inherit (old.llvmPackages) libraries release_version;
in
{ inherit tools libraries release_version; } // tools // libraries;
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
llvmPackages = super.llvmPackages // (
let
tools = super.llvmPackages.tools.extend (_: _: {
inherit (prevStage.llvmPackages) clang-unwrapped libclang libllvm llvm;
libcxxClang = lib.makeOverridable (import ../../build-support/cc-wrapper) {
nativeTools = false;
nativeLibc = false;
inherit (prevStage) expand-response-params;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraPackages = [
self.llvmPackages.compiler-rt
];
extraBuildCommands =
let
inherit (self.llvmPackages) clang-unwrapped compiler-rt release_version;
# Clang 16+ uses only the major version in resource-root, but older versions use the complete one.
clangResourceRootIncludePath = clangLib: clangRelease:
let
clangVersion =
if lib.versionAtLeast clangRelease "16"
then lib.versions.major clangRelease
else clangRelease;
in
"${clangLib}/lib/clang/${clangVersion}/include";
in
''
rsrc="$out/resource-root"
mkdir "$rsrc"
ln -s "${clangResourceRootIncludePath clang-unwrapped.lib release_version}" "$rsrc"
ln -s "${compiler-rt.out}/lib" "$rsrc/lib"
ln -s "${compiler-rt.out}/share" "$rsrc/share"
echo "-resource-dir=$rsrc" >> $out/nix-support/cc-cflags
'';
cc = self.llvmPackages.clang-unwrapped;
bintools = self.darwin.binutils;
isClang = true;
libc = self.darwin.Libsystem;
inherit (self.llvmPackages) libcxx;
inherit lib;
inherit (self) stdenvNoCC coreutils gnugrep runtimeShell;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
};
});
libraries = super.llvmPackages.libraries.extend (_: _:{
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
inherit (prevStage.llvmPackages) compiler-rt libcxx;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit tools libraries; } // tools // libraries
);
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
})
# Construct the final stdenv. The version of LLVM provided should match the one defined in
# `all-packages.nix` for Darwin. Nothing should depend on the bootstrap tools or originate from
# the bootstrap tools.
#
# When updating the Darwin stdenv, make sure that the result has no dependency (`nix-store -qR`)
# on `bootstrapTools` or the binutils built in stage 1.
(prevStage:
# previous stage4 stdenv:
assert lib.all isBuiltByNixpkgsCompiler (with prevStage; [
bash binutils-unwrapped brotli bzip2 cpio diffutils ed file findutils gawk
gettext gmp gnugrep gnumake gnused gnutar gzip icu libffi libiconv libidn2 libkrb5
libssh2 libunistring libxml2 libyaml ncurses nghttp2 openbsm openpam openssl patch
pbzx pcre python3Minimal xar xz zlib zstd
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [
binutils-unwrapped cctools libtapi locale print-reexports rewrite-tbd sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
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 01:56:50 +01:00
assert (! useAppleSDKLibs) -> lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [ Libsystem configd ]);
assert (! useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF Libsystem libobjc ]);
assert lib.all isFromNixpkgs (with prevStage.darwin; [ dyld launchd libclosure libdispatch xnu ]);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.llvmPackages; [
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
clang-unwrapped libclang libllvm llvm compiler-rt libcxx
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert lib.all isBuiltByBootstrapFilesCompiler (with prevStage; [
autoconf automake bison cmake cmakeMinimal cyrus_sasl db expat flex groff libedit
libtool m4 ninja openldap openssh patchutils perl pkg-config.pkg-config python3 scons
serf sqlite subversion sysctl.provider texinfo unzip which
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]);
assert prevStage.darwin.cctools == prevStage.darwin.cctools-llvm;
2021-06-02 06:25:56 +02:00
let
doSign = localSystem.isAarch64;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
cc = prevStage.llvmPackages.clang;
2021-06-02 06:25:56 +02:00
in
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
{
inherit config overlays;
stdenv = import ../generic {
2021-06-02 06:25:56 +02:00
name = "stdenv-darwin";
2021-06-02 06:25:56 +02:00
buildPlatform = localSystem;
hostPlatform = localSystem;
targetPlatform = localSystem;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit config;
preHook = ''
${commonPreHook}
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
export PATH_LOCALE=${prevStage.darwin.locale}/share/locale
'';
2020-11-19 09:28:20 +01:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
initialPath = ((import ../generic/common-path.nix) { pkgs = prevStage; });
2021-06-02 06:25:56 +02:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
prevStage.updateAutotoolsGnuConfigScriptsHook
] ++ [ prevStage.darwin.apple_sdk.sdkRoot ];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
extraBuildInputs = [ prevStage.darwin.CF ];
inherit cc;
shell = cc.shell;
inherit (prevStage.stdenv) fetchurlBoot;
2021-06-02 06:25:56 +02:00
extraAttrs = {
inherit bootstrapTools;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
libc = prevStage.darwin.Libsystem;
shellPackage = prevStage.bash;
} // lib.optionalAttrs useAppleSDKLibs {
# This objc4 will be propagated to all builds using the final stdenv,
# and we shouldn't mix different builds, because they would be
# conflicting LLVM modules. Export it here so we can grab it later.
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit (prevStage.darwin) objc4;
2021-06-02 06:25:56 +02:00
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
disallowedRequisites = [ bootstrapTools.out ];
allowedRequisites = (with prevStage; [
bash
binutils.bintools
binutils.bintools.lib
2021-06-02 06:25:56 +02:00
bzip2.bin
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
bzip2.out
cc.expand-response-params
2021-06-02 06:25:56 +02:00
coreutils
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
darwin.binutils
darwin.binutils.bintools
2021-06-02 06:25:56 +02:00
diffutils
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
ed
file
findutils
2021-06-02 06:25:56 +02:00
gawk
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
gettext
gmp.out
2021-06-02 06:25:56 +02:00
gnugrep
gnugrep.pcre2.out
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
gnumake
gnused
gnutar
gzip
icu.out
libffi.out
libiconv
libunistring.out
2021-06-02 06:25:56 +02:00
libxml2.out
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
ncurses.dev
ncurses.man
ncurses.out
openbsm
openpam
patch
xz.bin
xz.out
zlib.dev
zlib.out
]
++ lib.optionals doSign [ openssl.out ])
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
++ lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
]
++ (with prevStage.llvmPackages; [
bintools-unwrapped
clang-unwrapped
clang-unwrapped.lib
compiler-rt
compiler-rt.dev
2021-06-02 06:25:56 +02:00
libcxx
libcxx.dev
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
lld
2021-06-02 06:25:56 +02:00
llvm
llvm.lib
])
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
++ (with prevStage.darwin; [
2021-06-02 06:25:56 +02:00
CF
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
Libsystem
cctools-llvm
cctools-port
dyld
2021-06-02 06:25:56 +02:00
libtapi
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
locale
apple_sdk.sdkRoot
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
]
++ lib.optional useAppleSDKLibs [ objc4 ]
2021-06-02 06:25:56 +02:00
++ lib.optionals doSign [ postLinkSignHook sigtool signingUtils ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
__stdenvImpureHostDeps = commonImpureHostDeps;
__extraImpureHostDeps = commonImpureHostDeps;
overrides = self: super: {
inherit (prevStage)
bash binutils brotli bzip2 coreutils cpio diffutils ed file findutils gawk
gettext gmp gnugrep gnumake gnused gnutar gzip icu libffi libiconv libidn2 libssh2
libunistring libxml2 libyaml ncurses nghttp2 openbsm openpam openssl patch pbzx
pcre python3Minimal xar xz zlib zstd;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
darwin = super.darwin.overrideScope (_: superDarwin: {
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit (prevStage.darwin)
CF ICU Libsystem darwin-stubs dyld locale libobjc libtapi rewrite-tbd xnu;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
} // lib.optionalAttrs (super.stdenv.targetPlatform == localSystem) {
inherit (prevStage.darwin) binutils binutils-unwrapped cctools-llvm cctools-port;
2021-06-02 06:25:56 +02:00
});
} // lib.optionalAttrs (super.stdenv.targetPlatform == localSystem) {
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
inherit (prevStage.llvmPackages) clang llvm;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
# Need to get rid of these when cross-compiling.
llvmPackages = super.llvmPackages // (
let
tools = super.llvmPackages.tools.extend (_: _: {
inherit (prevStage.llvmPackages) clang clang-unwrapped libclang libllvm llvm;
});
libraries = super.llvmPackages.libraries.extend (_: _: {
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 11:53:37 +01:00
inherit (prevStage.llvmPackages) compiler-rt libcxx;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 09:03:00 +02:00
});
in
{ inherit tools libraries; } // tools // libraries
);
inherit (prevStage) binutils binutils-unwrapped;
};
};
})
# This "no-op" stage is just a place to put the assertions about stage6.
(prevStage:
# previous final stage stdenv:
assert isBuiltByNixpkgsCompiler prevStage.darwin.sigtool;
assert isBuiltByNixpkgsCompiler prevStage.darwin.binutils-unwrapped;
assert isBuiltByNixpkgsCompiler prevStage.darwin.print-reexports;
assert isBuiltByNixpkgsCompiler prevStage.darwin.rewrite-tbd;
assert isBuiltByNixpkgsCompiler prevStage.darwin.cctools;
assert isFromNixpkgs prevStage.darwin.CF;
assert isFromNixpkgs prevStage.darwin.Libsystem;
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.clang-unwrapped;
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.libllvm;
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.libcxx;
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.compiler-rt;
{ inherit (prevStage) config overlays stdenv; })
]