libiconvReal: make default on Darwin

[reckenrode]

The Darwin libiconv tries to be compatible with GNU libiconv, but it’s not. Recent versions of Autoconf and gnulib include checks for issues in Darwin’s libiconv implementation, which has effectively turned autoreconfHook into autoBreakDarwinHook due to failing to link libiconv. Instead of continuing to work around it, make GNU libiconv the default. With the UTF-8-MAC patch, it should be a drop-in replacement.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[reckenrode]

Oh, right. I forgot to split the stdenv changes out for this PR. I’ve added them to the last commit making GNU libiconv the default.

[reckenrode]

I fixed the eval error in pkgsStatic and rebasing on current staging.

[reckenrode]

I see that this was added to the Nixpkgs security review board. Another argument for using GNU libiconv over Apple’s libiconv is is that fixes for any vulnerabilities or issues found in the latter will only become available once Apple does a new code drop, which typically happens a few weeks to a month after the OS update is released.

[reckenrode]

Linking Homebrew and MacPorts discussions here. There are more links in the discussions as well.

• Homebrew:
  https://github.com/orgs/Homebrew/discussions/4884 and gettext: fix build on Sonoma Homebrew/homebrew-core#142490 (comment)
• MacPorts: https://trac.macports.org/ticket/68026#comment:13

These issues don’t affect us for a few reasons:

1. Our build of GNU libiconv takes steps to present a compatible ABI with the system one;
2. We delete all libiconv headers and stubs from the SDK. There is no way to mix them accidentally; and
3. The libiconv issue with GHC/stack has a fix applied because we want to use libiconv from Nixpkgs regardless.

[reckenrode]

In terms of testing, I’m using the following command. The only failure I have is nodejs-slim, which appears to be unrelated. It’s having issues with OpenSSL 3.6 and some other things. Previously known problematic builds like Git and libarchive, which failed due to requiring the UTF-8-MAC codec, build fine.

$ nix build -f . darwin.{AvailabilityVersions,DarwinTools,ICU,IOKitTools,adv_cmds,basic_cmds,binutils,binutils-unwrapped,binutilsDualAs,binutilsDualAs-unwrapped,binutilsNoLibc,bootstrap_cmds,copyfile,developer_cmds,diskdev_cmds,doc_cmds,dyld,file_cmds,libcxx,libffi,libiconv,libpcap,libresolv,libsbuf,libunwind,libutil,locale,lsusb,mail_cmds,misc_cmds,network_cmds,patch_cmds,ps,remote_cmds,removefile,shell_cmds,signingUtils,sigtool,system_cmds,text_cmds,top,trash,xattr} libunistring man-db dotnet-sdk_10 vulkan-caps-viewer mpv

[Eveeifyeve]

I see no issues with this from diff and homebrew/macports concerns mentioned to have this change be merged. The nodejs-slim issue is related to openssl which should be fixed in a completely different pr IMO.

[reckenrode]

My pushes have been rebasing the PR on current staging.

[reckenrode]

There appears to be a (trivial) diff between the patch source and the vendored patch:

I changed it to use fetchurl. If I’m going to be setting patchFlags to -p0 anyway, then I might as well do that. The original reason for vendoring was that I can’t use fetchpatch2 (e.g., with extraPrefix) because it causes an infinite recursion in the Darwin stdenv bootstrap.

[reckenrode]

Once @emilazy weighs in, and she approves, I’ll merge and give #511329 a heads up.

[reckenrode]

The nodejs-slim issue is related to openssl which should be fixed in a completely different pr IMO.

I agree the nodejs-slim issues should be addressed in another PR. I was noting that problem because it the only thing in my testing that failed to build. The OpenSSL problem (fixed in #510554) is not the only one though. I ended up also having to disable the following tests. I’m not opening a PR for that because I don’t know whether it’s the right fix. My goal was only getting to the point I can build .NET and mpv.

"test-esm-import-meta-main-eval"
"test-worker-debug"
"test-worker-track-unmanaged-fds"

After that, everything except for python313Packages.aiohttp built, which is failing due to the CVE-2026-3644 fix in #508075. There is an open PR upstream to fix it at aio-libs/aiohttp#12395, but I’ll leave it for the maintainers to cherry-pick or for upstream to commit a fix. I’m not touching something sensitive outside my usual area that just to fix a build.