包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载本文为 nixpkgs 中 DarwinmacOS标准构建环境stdenv的专项技术指南围绕 pkgs/stdenv/darwin/README.md 中阐述的两条核心设计目标——“开启沙箱也能构建 stdenv”与“输出对 bootstrap 工具的弱依赖”——展开并结合 pkgs/stdenv/darwin/default.nix 的分阶段自举源码、pkgs/top-level/all-packages.nix 中 LLVM 版本的实际绑定完整讲解 Darwin stdenv 如何升级 LLVM、如何修复升级导致的破坏以及如何在仓库内验证一次 stdenv 自举。读完后你将能够独立完成一次 Darwin stdenv 的 LLVM 版本升级并理解每阶段自举断言assert背后的原理。一、Darwin stdenv 在 nixpkgs 中的位置nixpkgs 的 stdenv 选择入口是 pkgs/stdenv/default.nix它根据localSystem把各平台的自举阶段列表boot stages分发出去Darwin 分支直接 import 独立目录stagesDarwin import ./darwin bootArgs; # ... bootStages if localSystem.isLinux then stagesLinux else if localSystem.isDarwin then stagesDarwin else /* Solaris/FreeBSD/native 兜底 */;见 pkgs/stdenv/default.nix#L48 与 pkgs/stdenv/default.nix#L50-L60。Darwin 的实现文件头部注释明确指出它基于 LLVM模仿 Linux stdenv 的结构目标同样是“构建结果纯净、不残留对本机环境的引用”并指向本 README 阅读设计细节pkgs/stdenv/darwin/default.nix#L1-L8。从源码结构看当前 Darwin stdenv 只支持aarch64-darwinbootstrapFiles参数只 import 了 aarch64-apple-darwin.nix其余平台直接throw Unsupported platform for the Darwin stdenvpkgs/stdenv/darwin/default.nix#L15-L21。这是使用该 stdenv 的前提限制。二、README 的两条设计目标及其源码证据pkgs/stdenv/darwin/README.md 开篇明确列出两条值得单独强调的设计目标两者都在实现中有对应机制。目标 1开启沙箱也能成功构建 stdenvREADME 原文要求标准环境在 Darwin 上启用沙箱sandboxing时应当构建成功。某个包确实需要sandboxProfile没关系但构建 stdenv 本身不应依赖关闭沙箱。在 pkgs/stdenv/darwin/default.nix 中可以看到为“纯净/受约束构建”服务的显式设置每个阶段的 stdenv 都会注入一个公共 preHook强制开启 Nix 的纯度检查pkgs/stdenv/darwin/default.nix#L54-L58commonPreHook export NIX_ENFORCE_NO_NATIVE${NIX_ENFORCE_NO_NATIVE-1} export NIX_ENFORCE_PURITY${NIX_ENFORCE_PURITY-1} export NIX_IGNORE_LD_THROUGH_GCC1 ;NIX_ENFORCE_NO_NATIVE1会禁止访问__stdenvImpureHostDeps之外的本机路径。Darwin stdenv 将本机依赖收敛到极小的白名单/bin/sh、libSystem.B.dylib、libunc.dylib见 pkgs/stdenv/darwin/default.nix#L31-L35使构建只依赖系统最基本的运行时符号从而能够放在沙箱里跑——这正是“可以沙箱构建”在实现层面的含义构建过程对宿主机的访问面被限定到几乎最小。最终 stdenv 还声明了disallowedRequisites [ bootstrapTools.out ]pkgs/stdenv/darwin/default.nix#L1006即产物中不允许出现对 bootstrap 工具包的引用与下一目标直接呼应。目标 2输出对 bootstrap 工具只保持“弱依赖”README 指出历史上 Darwin 升级 stdenv 时必须先更新 bootstrap 工具才能更新标准环境里使用的 LLVM 版本。改造后的目标是不依赖特定版本的 bootstrap 工具这样升级 Darwin 所用的 LLVM 只需要 bumpall-packages.nix中的llvmPackages定义即可。源码中这一设计有两处关键支撑bootstrap 工具包是内容寻址content-addressed的它只是一个“启动引导”输入而非产物的依赖项pkgs/stdenv/darwin/default.nix#L60-L88bootstrapTools derivation ( { name bootstrap-tools; builder ${bootstrapFiles.unpack}/bin/bash; args [ ${bootstrapFiles.unpack}/bootstrap-tools-unpack.sh bootstrapFiles.bootstrapTools ]; # ... } // lib.optionalAttrs config.contentAddressedByDefault { __contentAddressed true; outputHashAlgo sha256; outputHashMode recursive; } ) // { passthru.isFromBootstrapFiles true; };内容寻址意味着只要 bootstrap 工具包内容不变其 store 路径就稳定stdenv 的 hash 不会因它漂移而passthru.isFromBootstrapFiles标签则供各阶段的断言区分“来自 bootstrap 工具”与“来自 nixpkgs 自举”的包。每阶段的断言链强制 LLVM 逐步脱离 bootstrap 工具。default.nix用一组判定函数isFromBootstrapFiles、isBuiltByNixpkgsCompiler、isFromNixpkgs等L37-L40对每个阶段的输入包做属性断言例如 stage-xclang 之前要求 LLVM 工具仍来自 bootstrap 文件而 stage3 之后要求compiler-rt、libcxx已由 nixpkgs 自举的编译器构建pkgs/stdenv/darwin/default.nix#L654-L671。最终阶段还有一个“no-op 断言 stage”兜底确认 cctools、ld64、clang、libllvm、compiler-rt、curl 等全部由 nixpkgs 编译器构建pkgs/stdenv/darwin/default.nix#L1156-L1179。这套断言把“弱依赖”从口头目标变成了求值期可验证的不变量。三、更新 Darwin stdenv 的完整步骤README 主体pkgs/stdenv/darwin/README.md 的核心内容是更新流程实际上是两步步骤 1把 Darwin 的 llvmPackages 对齐到 llvmPackages.latestREADME 原文把all-packages.nix中 Darwin 对应的llvmPackages定义更新为与llvmPackages.latest相同的值。在仓库中可以对应到两处必须同步的位置pkgs/top-level/all-packages.nix#L3796llvmPackages llvmPackages_21;当前仓库中latest绑定为 21而可用版本集由llvmPackagesSet提供 1823 共 6 个版本pkgs/top-level/all-packages.nix#L3798-L3814pkgs/stdenv/darwin/default.nix#L28llvmVersion 21; # This needs to be updated when the default LLVM version is changed.——Darwin stdenv 内部按版本号引用llvmPackages_${llvmVersion}升级时这个字面量必须与all-packages.nix保持一致否则各阶段的assert allDeps断言会因属性缺失而失败。时机要求README 原文要点目前按 LLVM 的春季版本spring release节奏执行等llvmPackages.latest更新到对应版本后再动如果 LLVM 项目已公布后续补丁patch更新计划则等这些补丁版本进入 Nixpkgs 之后再升级若上述条件不满足例如补丁版本尚未就绪LLVM 升级 PR 不能直接合入 master必须走staging 分支。步骤 2修复升级导致的破坏breakageREADME 对破坏模式与修复策略的说明需要完整保留破坏的典型来源新 LLVM 把更多警告提升为错误或整体收紧了严格性导致 stdenv 自举链中的包编译失败两种修复手段关闭/禁用新增的警告直接修复源代码本身打补丁或向上游提交更新原则如果问题是琐碎的README 举例implicit function declaration 缺一个int返回类型应当修好问题本身而不是压制警告。从源码结构看这类“升级后修复”最常落在自举链里对个别包的overrideAttrs上——default.nix中已经保留了大量先例例如为 ld64 关闭 install-check依赖的 LTO 库彼时尚未构建、为 gettext 换用libiconvReal打破循环、把 pkg-config 换为 libpkgconf 以避免arpa/nameser.h缺失等pkgs/stdenv/darwin/default.nix#L550-L604。这些注释本身就是一份“哪些坑是真实踩出来的”清单对排查新版 LLVM 引入的同类错误有直接参考价值。升级完成后的验证default.nix最终阶段注释给出了 README 步骤之外的验收标准pkgs/stdenv/darwin/default.nix#L941-L946更新 Darwin stdenv 时务必用nix-store -qR确认结果不依赖bootstrapTools或 stage 1 构建的 binutils。即对最终stdenv做递归依赖闭包检查出现bootstrapTools的输出路径即说明自举断言体系之外的隐性残留需要回溯是哪个阶段泄漏了 bootstrap 工具。四、自举管线全景从 bootstrap 工具到最终 stdenv 的 7 个阶段理解“如何更新”之前有必要知道 stdenv 是如何被自举出来的。pkgs/stdenv/darwin/default.nix#L298 起返回一个函数列表每个元素是一个自举阶段各阶段仅依赖上一阶段prevStage不跨阶段取包这由注释和mergeDisjointAttrs依赖集必须互斥共同保证。阶段名职责源码注释归纳__raw初始阶段全部关键包置null的占位起点L299-L334bootstrap-stage0用 bootstrap 工具包展开环境symlink 出 clang/libllvm/libcxx/compiler-rt 等file等缺失包置 nullL341-L508bootstrap-stage1确定核心依赖版本构建 CFCoreFoundation与 Libsystem使断言在 x86_64/aarch64 上假设一致此阶段起binutils-unwrapped、curl被显式throw禁止使用L513-L548bootstrap-stage-xclang第一次用 nixpkgs 源重建 LLVM编译器本体后续会再重建但其产出的 compiler-rt、libc、libcabi 进入最终 stdenvL648-L651bootstrap-stage2重建 SDK并用新 bash 重建需要打进补丁 shebang 的组件L719-L720bootstrap-stage3用 LLVM 重建 LLVM同时重建 SDK 以拾取新的 cctools/libtoolL798-L799bootstrap-stage4用新 clang 重建最终 stdenv 的全部组成产出stdenv-darwinL874-L875收尾断言阶段no-op 阶段只放置对最终产物的assertL1156-L1179每阶段都通过assert allDeps 判定函数 [...]校验“本阶段输入包的来源是否符合预期”例如 stage3 要求bintools/llvmTools由 bootstrap 编译器构建、sdkPackages已由 nixpkgs 编译器构建pkgs/stdenv/darwin/default.nix#L802-L820。升级 LLVM 后如果某阶段的断言失败报错信息会精确给出违例包列表——这是步骤 2“修复破坏”的第一手线索。此外所有构建阶段的 preHook 都设置stripDebugFlags-S因为llvm-strip对 Mach-O 不支持-ppkgs/stdenv/darwin/default.nix#L504-L506这是 Darwin 与 Linux stdenv 的一个细节差异。五、bootstrap 工具的生成、替换与验证既然目标 2 是“弱依赖 bootstrap 工具”那么 bootstrap 工具本身如何更新仓库提供了独立的工具链生成pkgs/stdenv/darwin/stdenv-bootstrap-tools.nix 把 coreutils、bash、grep、make、clang、libc、curl、sigtool、jq、llvm-readtapi等拷贝到一个自包含目录再执行rpathify把 store 绝对路径改写为rpath引用并补 rpath、checkDeps、nuke-refs清理 Nix store 路径引用最终产出on-server/bootstrap-tools.tar.xz与unpack.nar.xz两个工件pkgs/stdenv/darwin/stdenv-bootstrap-tools.nix#L264-L284。发布与固定产物上传到 tarball 服务器后由maintainers/scripts/bootstrap-files/下的刷新脚本回写 bootstrap-files/aarch64-apple-darwin.nix其中记录生成时的 nixpkgs revision、hydra 构建与哈希当前固定于 2025 年 2 月构建的 aarch64 工件。替换入口stdenv 的bootstrapFiles参数可被config.replaceBootstrapFiles覆盖pkgs/stdenv/darwin/default.nix#L15-L21注释明确其用途是“在改动 bootstrap 工具时测试 stdenv 自举流程”。验证pkgs/stdenv/darwin/make-bootstrap-tools.nix 暴露了test-pkgs——“终极测试用指定的工具包完整自举出一个 stdenv 并产出包集合”可用nix-build -A freshBootstrapTools.test-pkgs.stdenv运行pkgs/stdenv/darwin/make-bootstrap-tools.nix#L39-L54轻量的 test-bootstrap-tools.nix 则逐项冒烟遍历$tools/bin/*执行--version、用 bootstrap clang 编译 C/C hello 程序、校验 libc rpath、用 curl 断言 SSL 支持并在最小环境中用./configure make make install构建 hello 完成端到端验证pkgs/stdenv/darwin/test-bootstrap-tools.nix#L30-L91。这也解释了 README 的历史沿革过去“先更新 bootstrap 工具再升 LLVM”是因为产物 hash 会随 bootstrap 工具版本漂移现在工具包内容寻址 断言体系保证 LLVM 升级与工具刷新解耦——日常升级 stdenv 不再需要触碰 bootstrap 工件。六、关键文件索引文件作用pkgs/stdenv/darwin/README.md设计目标与更新流程本文主体依据pkgs/stdenv/darwin/default.nix7 阶段自举实现、阶段断言、llvmVersion绑定pkgs/stdenv/darwin/bootstrap-tools.nix展开 bootstrap 工具包的轻量 derivationpkgs/stdenv/darwin/stdenv-bootstrap-tools.nixbootstrap 工具包的装配、rpath 化与打包pkgs/stdenv/darwin/make-bootstrap-tools.nixtest-pkgs全量自举验证入口pkgs/stdenv/darwin/test-bootstrap-tools.nix工具包冒烟测试pkgs/stdenv/darwin/bootstrap-files/aarch64-apple-darwin.nix固定的 aarch64 bootstrap 工件与哈希pkgs/stdenv/default.nix按localSystem.isDarwin分发 Darwin stdenvpkgs/top-level/all-packages.nixllvmPackages版本绑定升级步骤 1 的落点七、总结Darwin stdenv 的设计可以浓缩为一句话用内容寻址的 bootstrap 工具做一次性点火用分阶段断言保证产物对工具的零残留依赖。升级 LLVM 时操作面被压缩到“bumpall-packages.nix的llvmPackages 同步darwin/default.nix的llvmVersion 修复新增警告错误”三件事修复时优先修源码而非静默警告时机上跟随 LLVM 春季版本与补丁节奏未就绪则走 staging。所有验收都可以落到可执行的检查上阶段断言在求值期拦截依赖泄漏nix-store -qR与nix-build -A freshBootstrapTools.test-pkgs.stdenv则在构建期兜底。这套机制使 Darwin stdenv 的每次升级都成为一次可审计、可复现的工程操作而非对 bootstrap 工件的全局重放。赞分享包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载相关推荐Hyperf 异常处理机制完全指南从自定义 Exception Handler 到 Whoops 调试与 Error ListenerHyperf 异常处理机制完全指南从自定义 Exception Handler 到 Whoops 调试与 Error Listener 导读 Hyperf 框后端微服务AntiDupl.NET终极免费开源图片去重神器3步快速释放硬盘空间AntiDupl.NET终极免费开源图片去重神器3步快速释放硬盘空间 你的电脑硬盘是否经常告急手机相册里是否充满了重复的照片 AntiDupl.NET图像处理桌面应用Nixpkgs Darwin (macOS) 平台打包实战指南stdenv 差异、SDK 与部署目标排查Nixpkgs Darwin macOS 平台打包实战指南stdenv 差异、SDK 与部署目标排查 本篇指南聚焦于 Nixpkgs 中 Darwinmac包管理器操作系统上一篇终极Vim状态栏插件开发指南打造个性化工作区下一篇Switchyard架构深度剖析请求从进站到出站的全生命周期创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/9 2:36:21 · 阅读 1.2k nixpkgs Darwin stdenv：沙箱纯构建、弱依赖 bootstrap 工具与 LLVM 升级全流程
包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载本文为 nixpkgs 中 DarwinmacOS标准构建环境stdenv的专项技术指南围绕 pkgs/stdenv/darwin/README.md 中阐述的两条核心设计目标——“开启沙箱也能构建 stdenv”与“输出对 bootstrap 工具的弱依赖”——展开并结合 pkgs/stdenv/darwin/default.nix 的分阶段自举源码、pkgs/top-level/all-packages.nix 中 LLVM 版本的实际绑定完整讲解 Darwin stdenv 如何升级 LLVM、如何修复升级导致的破坏以及如何在仓库内验证一次 stdenv 自举。读完后你将能够独立完成一次 Darwin stdenv 的 LLVM 版本升级并理解每阶段自举断言assert背后的原理。一、Darwin stdenv 在 nixpkgs 中的位置nixpkgs 的 stdenv 选择入口是 pkgs/stdenv/default.nix它根据localSystem把各平台的自举阶段列表boot stages分发出去Darwin 分支直接 import 独立目录stagesDarwin import ./darwin bootArgs; # ... bootStages if localSystem.isLinux then stagesLinux else if localSystem.isDarwin then stagesDarwin else /* Solaris/FreeBSD/native 兜底 */;见 pkgs/stdenv/default.nix#L48 与 pkgs/stdenv/default.nix#L50-L60。Darwin 的实现文件头部注释明确指出它基于 LLVM模仿 Linux stdenv 的结构目标同样是“构建结果纯净、不残留对本机环境的引用”并指向本 README 阅读设计细节pkgs/stdenv/darwin/default.nix#L1-L8。从源码结构看当前 Darwin stdenv 只支持aarch64-darwinbootstrapFiles参数只 import 了 aarch64-apple-darwin.nix其余平台直接throw Unsupported platform for the Darwin stdenvpkgs/stdenv/darwin/default.nix#L15-L21。这是使用该 stdenv 的前提限制。二、README 的两条设计目标及其源码证据pkgs/stdenv/darwin/README.md 开篇明确列出两条值得单独强调的设计目标两者都在实现中有对应机制。目标 1开启沙箱也能成功构建 stdenvREADME 原文要求标准环境在 Darwin 上启用沙箱sandboxing时应当构建成功。某个包确实需要sandboxProfile没关系但构建 stdenv 本身不应依赖关闭沙箱。在 pkgs/stdenv/darwin/default.nix 中可以看到为“纯净/受约束构建”服务的显式设置每个阶段的 stdenv 都会注入一个公共 preHook强制开启 Nix 的纯度检查pkgs/stdenv/darwin/default.nix#L54-L58commonPreHook export NIX_ENFORCE_NO_NATIVE${NIX_ENFORCE_NO_NATIVE-1} export NIX_ENFORCE_PURITY${NIX_ENFORCE_PURITY-1} export NIX_IGNORE_LD_THROUGH_GCC1 ;NIX_ENFORCE_NO_NATIVE1会禁止访问__stdenvImpureHostDeps之外的本机路径。Darwin stdenv 将本机依赖收敛到极小的白名单/bin/sh、libSystem.B.dylib、libunc.dylib见 pkgs/stdenv/darwin/default.nix#L31-L35使构建只依赖系统最基本的运行时符号从而能够放在沙箱里跑——这正是“可以沙箱构建”在实现层面的含义构建过程对宿主机的访问面被限定到几乎最小。最终 stdenv 还声明了disallowedRequisites [ bootstrapTools.out ]pkgs/stdenv/darwin/default.nix#L1006即产物中不允许出现对 bootstrap 工具包的引用与下一目标直接呼应。目标 2输出对 bootstrap 工具只保持“弱依赖”README 指出历史上 Darwin 升级 stdenv 时必须先更新 bootstrap 工具才能更新标准环境里使用的 LLVM 版本。改造后的目标是不依赖特定版本的 bootstrap 工具这样升级 Darwin 所用的 LLVM 只需要 bumpall-packages.nix中的llvmPackages定义即可。源码中这一设计有两处关键支撑bootstrap 工具包是内容寻址content-addressed的它只是一个“启动引导”输入而非产物的依赖项pkgs/stdenv/darwin/default.nix#L60-L88bootstrapTools derivation ( { name bootstrap-tools; builder ${bootstrapFiles.unpack}/bin/bash; args [ ${bootstrapFiles.unpack}/bootstrap-tools-unpack.sh bootstrapFiles.bootstrapTools ]; # ... } // lib.optionalAttrs config.contentAddressedByDefault { __contentAddressed true; outputHashAlgo sha256; outputHashMode recursive; } ) // { passthru.isFromBootstrapFiles true; };内容寻址意味着只要 bootstrap 工具包内容不变其 store 路径就稳定stdenv 的 hash 不会因它漂移而passthru.isFromBootstrapFiles标签则供各阶段的断言区分“来自 bootstrap 工具”与“来自 nixpkgs 自举”的包。每阶段的断言链强制 LLVM 逐步脱离 bootstrap 工具。default.nix用一组判定函数isFromBootstrapFiles、isBuiltByNixpkgsCompiler、isFromNixpkgs等L37-L40对每个阶段的输入包做属性断言例如 stage-xclang 之前要求 LLVM 工具仍来自 bootstrap 文件而 stage3 之后要求compiler-rt、libcxx已由 nixpkgs 自举的编译器构建pkgs/stdenv/darwin/default.nix#L654-L671。最终阶段还有一个“no-op 断言 stage”兜底确认 cctools、ld64、clang、libllvm、compiler-rt、curl 等全部由 nixpkgs 编译器构建pkgs/stdenv/darwin/default.nix#L1156-L1179。这套断言把“弱依赖”从口头目标变成了求值期可验证的不变量。三、更新 Darwin stdenv 的完整步骤README 主体pkgs/stdenv/darwin/README.md 的核心内容是更新流程实际上是两步步骤 1把 Darwin 的 llvmPackages 对齐到 llvmPackages.latestREADME 原文把all-packages.nix中 Darwin 对应的llvmPackages定义更新为与llvmPackages.latest相同的值。在仓库中可以对应到两处必须同步的位置pkgs/top-level/all-packages.nix#L3796llvmPackages llvmPackages_21;当前仓库中latest绑定为 21而可用版本集由llvmPackagesSet提供 1823 共 6 个版本pkgs/top-level/all-packages.nix#L3798-L3814pkgs/stdenv/darwin/default.nix#L28llvmVersion 21; # This needs to be updated when the default LLVM version is changed.——Darwin stdenv 内部按版本号引用llvmPackages_${llvmVersion}升级时这个字面量必须与all-packages.nix保持一致否则各阶段的assert allDeps断言会因属性缺失而失败。时机要求README 原文要点目前按 LLVM 的春季版本spring release节奏执行等llvmPackages.latest更新到对应版本后再动如果 LLVM 项目已公布后续补丁patch更新计划则等这些补丁版本进入 Nixpkgs 之后再升级若上述条件不满足例如补丁版本尚未就绪LLVM 升级 PR 不能直接合入 master必须走staging 分支。步骤 2修复升级导致的破坏breakageREADME 对破坏模式与修复策略的说明需要完整保留破坏的典型来源新 LLVM 把更多警告提升为错误或整体收紧了严格性导致 stdenv 自举链中的包编译失败两种修复手段关闭/禁用新增的警告直接修复源代码本身打补丁或向上游提交更新原则如果问题是琐碎的README 举例implicit function declaration 缺一个int返回类型应当修好问题本身而不是压制警告。从源码结构看这类“升级后修复”最常落在自举链里对个别包的overrideAttrs上——default.nix中已经保留了大量先例例如为 ld64 关闭 install-check依赖的 LTO 库彼时尚未构建、为 gettext 换用libiconvReal打破循环、把 pkg-config 换为 libpkgconf 以避免arpa/nameser.h缺失等pkgs/stdenv/darwin/default.nix#L550-L604。这些注释本身就是一份“哪些坑是真实踩出来的”清单对排查新版 LLVM 引入的同类错误有直接参考价值。升级完成后的验证default.nix最终阶段注释给出了 README 步骤之外的验收标准pkgs/stdenv/darwin/default.nix#L941-L946更新 Darwin stdenv 时务必用nix-store -qR确认结果不依赖bootstrapTools或 stage 1 构建的 binutils。即对最终stdenv做递归依赖闭包检查出现bootstrapTools的输出路径即说明自举断言体系之外的隐性残留需要回溯是哪个阶段泄漏了 bootstrap 工具。四、自举管线全景从 bootstrap 工具到最终 stdenv 的 7 个阶段理解“如何更新”之前有必要知道 stdenv 是如何被自举出来的。pkgs/stdenv/darwin/default.nix#L298 起返回一个函数列表每个元素是一个自举阶段各阶段仅依赖上一阶段prevStage不跨阶段取包这由注释和mergeDisjointAttrs依赖集必须互斥共同保证。阶段名职责源码注释归纳__raw初始阶段全部关键包置null的占位起点L299-L334bootstrap-stage0用 bootstrap 工具包展开环境symlink 出 clang/libllvm/libcxx/compiler-rt 等file等缺失包置 nullL341-L508bootstrap-stage1确定核心依赖版本构建 CFCoreFoundation与 Libsystem使断言在 x86_64/aarch64 上假设一致此阶段起binutils-unwrapped、curl被显式throw禁止使用L513-L548bootstrap-stage-xclang第一次用 nixpkgs 源重建 LLVM编译器本体后续会再重建但其产出的 compiler-rt、libc、libcabi 进入最终 stdenvL648-L651bootstrap-stage2重建 SDK并用新 bash 重建需要打进补丁 shebang 的组件L719-L720bootstrap-stage3用 LLVM 重建 LLVM同时重建 SDK 以拾取新的 cctools/libtoolL798-L799bootstrap-stage4用新 clang 重建最终 stdenv 的全部组成产出stdenv-darwinL874-L875收尾断言阶段no-op 阶段只放置对最终产物的assertL1156-L1179每阶段都通过assert allDeps 判定函数 [...]校验“本阶段输入包的来源是否符合预期”例如 stage3 要求bintools/llvmTools由 bootstrap 编译器构建、sdkPackages已由 nixpkgs 编译器构建pkgs/stdenv/darwin/default.nix#L802-L820。升级 LLVM 后如果某阶段的断言失败报错信息会精确给出违例包列表——这是步骤 2“修复破坏”的第一手线索。此外所有构建阶段的 preHook 都设置stripDebugFlags-S因为llvm-strip对 Mach-O 不支持-ppkgs/stdenv/darwin/default.nix#L504-L506这是 Darwin 与 Linux stdenv 的一个细节差异。五、bootstrap 工具的生成、替换与验证既然目标 2 是“弱依赖 bootstrap 工具”那么 bootstrap 工具本身如何更新仓库提供了独立的工具链生成pkgs/stdenv/darwin/stdenv-bootstrap-tools.nix 把 coreutils、bash、grep、make、clang、libc、curl、sigtool、jq、llvm-readtapi等拷贝到一个自包含目录再执行rpathify把 store 绝对路径改写为rpath引用并补 rpath、checkDeps、nuke-refs清理 Nix store 路径引用最终产出on-server/bootstrap-tools.tar.xz与unpack.nar.xz两个工件pkgs/stdenv/darwin/stdenv-bootstrap-tools.nix#L264-L284。发布与固定产物上传到 tarball 服务器后由maintainers/scripts/bootstrap-files/下的刷新脚本回写 bootstrap-files/aarch64-apple-darwin.nix其中记录生成时的 nixpkgs revision、hydra 构建与哈希当前固定于 2025 年 2 月构建的 aarch64 工件。替换入口stdenv 的bootstrapFiles参数可被config.replaceBootstrapFiles覆盖pkgs/stdenv/darwin/default.nix#L15-L21注释明确其用途是“在改动 bootstrap 工具时测试 stdenv 自举流程”。验证pkgs/stdenv/darwin/make-bootstrap-tools.nix 暴露了test-pkgs——“终极测试用指定的工具包完整自举出一个 stdenv 并产出包集合”可用nix-build -A freshBootstrapTools.test-pkgs.stdenv运行pkgs/stdenv/darwin/make-bootstrap-tools.nix#L39-L54轻量的 test-bootstrap-tools.nix 则逐项冒烟遍历$tools/bin/*执行--version、用 bootstrap clang 编译 C/C hello 程序、校验 libc rpath、用 curl 断言 SSL 支持并在最小环境中用./configure make make install构建 hello 完成端到端验证pkgs/stdenv/darwin/test-bootstrap-tools.nix#L30-L91。这也解释了 README 的历史沿革过去“先更新 bootstrap 工具再升 LLVM”是因为产物 hash 会随 bootstrap 工具版本漂移现在工具包内容寻址 断言体系保证 LLVM 升级与工具刷新解耦——日常升级 stdenv 不再需要触碰 bootstrap 工件。六、关键文件索引文件作用pkgs/stdenv/darwin/README.md设计目标与更新流程本文主体依据pkgs/stdenv/darwin/default.nix7 阶段自举实现、阶段断言、llvmVersion绑定pkgs/stdenv/darwin/bootstrap-tools.nix展开 bootstrap 工具包的轻量 derivationpkgs/stdenv/darwin/stdenv-bootstrap-tools.nixbootstrap 工具包的装配、rpath 化与打包pkgs/stdenv/darwin/make-bootstrap-tools.nixtest-pkgs全量自举验证入口pkgs/stdenv/darwin/test-bootstrap-tools.nix工具包冒烟测试pkgs/stdenv/darwin/bootstrap-files/aarch64-apple-darwin.nix固定的 aarch64 bootstrap 工件与哈希pkgs/stdenv/default.nix按localSystem.isDarwin分发 Darwin stdenvpkgs/top-level/all-packages.nixllvmPackages版本绑定升级步骤 1 的落点七、总结Darwin stdenv 的设计可以浓缩为一句话用内容寻址的 bootstrap 工具做一次性点火用分阶段断言保证产物对工具的零残留依赖。升级 LLVM 时操作面被压缩到“bumpall-packages.nix的llvmPackages 同步darwin/default.nix的llvmVersion 修复新增警告错误”三件事修复时优先修源码而非静默警告时机上跟随 LLVM 春季版本与补丁节奏未就绪则走 staging。所有验收都可以落到可执行的检查上阶段断言在求值期拦截依赖泄漏nix-store -qR与nix-build -A freshBootstrapTools.test-pkgs.stdenv则在构建期兜底。这套机制使 Darwin stdenv 的每次升级都成为一次可审计、可复现的工程操作而非对 bootstrap 工件的全局重放。赞分享包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载相关推荐Hyperf 异常处理机制完全指南从自定义 Exception Handler 到 Whoops 调试与 Error ListenerHyperf 异常处理机制完全指南从自定义 Exception Handler 到 Whoops 调试与 Error Listener 导读 Hyperf 框后端微服务AntiDupl.NET终极免费开源图片去重神器3步快速释放硬盘空间AntiDupl.NET终极免费开源图片去重神器3步快速释放硬盘空间 你的电脑硬盘是否经常告急手机相册里是否充满了重复的照片 AntiDupl.NET图像处理桌面应用Nixpkgs Darwin (macOS) 平台打包实战指南stdenv 差异、SDK 与部署目标排查Nixpkgs Darwin macOS 平台打包实战指南stdenv 差异、SDK 与部署目标排查 本篇指南聚焦于 Nixpkgs 中 Darwinmac包管理器操作系统上一篇终极Vim状态栏插件开发指南打造个性化工作区下一篇Switchyard架构深度剖析请求从进站到出站的全生命周期创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考