darwin.libcxx: (╯°□°）╯︵ ┻━┻

[reckenrode]

Darwin currently uses libc++ from nixpkgs, but it probably shouldn’t (at least not by default). The libc++ that is built in nixpkgs comes from LLVM. According to Louis Dionne (of Apple and a member of the C++ committee), the libc++ shipped by Apple should be considered distinct from the libc++ in LLVM. We’ve been lucky that we have not had problems with ODR violations. This PR was prompted by leakage of symbols from the system libc++ that started happening with the release of macOS 15.4. It changes a number of things to improve the compatibility of C++ on Darwin.

• It makes the system libc++ the default C++. The Darwin bootstrap is built against it. The default stdenv uses it. This is done by making the libc++ headers and text-based stubs available from the 15.2 SDK. This is safe to do because using symbols that are not available on your deployment target results in a compile-time error.

Testing

I also confirmed that all of the packages updated in this PR built (except for servo, which is broken due to Darwin having a case-insensitive build location), that Qt 5 and opencv4 built on x86_64-darwin, and that my configs built (except for util-linux, which appears broken again on Darwin).

Breaking Change

The primary points of breakage are as follows:

• Packages (such as Bazel and MoltenVK) that work around #150655 by referencing libcxx should instead reference stdenv.cc.libcxx. (Those are also fixed in this PR.)
• The system libc++ expects Clang 16 or newer (due to libc++ support policies). To build with an older Clang, you need to override the SDK used by libc++ to make it use older libc++ headers.
• overrideLibcxx doesn’t work with the system libc++. If you really need to use it, you should use it with llvmPackages.libcxxStdenv.

Notes about fixed packages

• Several packages depend on qt6.qtdeclarative, but it doesn’t build. Fixed in #398849.
• python3Packages.py3exid2 looks for Boost in /usr/local/lib. Fixed in #399005.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[reckenrode]

Fixed the signatures. I think I’m going to need to look into Sequoia as a replacement for GnuPG ….

Anyway, I confirmed that all of the packages changed in this PR build except for servo, which fails due to having README.md and Readme.md in one of its vendored crates (i.e., case-insensitive /tmp issues). I also confirmed that both Qt 5 and opencv4 build with their workarounds reverted from the last staging-next cycle.

[emilazy]

Needs rebase; otherwise LGTM. Left a comment about the one unresolved thing (version).

[emilazy]

overrideLibcxx in pkgs/stdenv/adapters.nix does, I wonder who we should blame for that? 😆

But since Swift and Qt 5 are the only user (and hopefully Swift won’t be soon? and the Qt 5 one seems dubious to me), that’s hopefully not the end of the world; we can potentially just drop it and the assertion is harmless anyway since 15 > 12.

This is not a blocker for me, but it would be nice for the package name in the store path to be distinguished from an LLVM one, and maybe we can solve both problems at once. Some proposals:

• libcxx-apple-sdk-15.2
• libcxx-0-apple-sdk-15.2 (ensures version comparisons will at least fail harder)

I think that ideally, we’d have something like libcxx-⟨closest upstream LLVM version⟩-apple-sdk-⟨macOS SDK version⟩. But it might be hard to reliably determine the corresponding LLVM version, given what Apple’s tree is like.

[philiptaron]

Woohoo!