MNT: Bump to 0.16.0 (osx-arm64 + linux-aarch64 green)

[tdejager]

Summary

Bumps zig to 0.16.0. Rebases the MacOS and Linux patch stacks against 0.16 internals and gets both osx-arm64 and linux-aarch64 building and testing cleanly end-to-end. Drops 3 patches that are obsolete in 0.16. Windows (non_unix/*) and ppc64le stacks are deliberately left un-rebased in this PR and those targets will fail CI until a follow-up.

Toolchain / environment

• Source URL moved to codeberg (upstream repo migrated; GitHub tag for 0.16.0 does not exist).
• LLVM 20 → 21 everywhere (0.16 hard-requires 21.x at CMake configure time).
• Clang/clangxx 20 → 21 on osx.
• linux-aarch64 c_stdlib_version 2.17 → 2.28 — zig 0.16's stage2 C transpile emits getrandom / copy_file_range / statx, none of which are in glibc 2.17. Other linux variants will likely need the same bump when they're rebased.
• Added aarch64-conda-linux-gnu to build_triplet. Native linux-aarch64 builds were previously unreachable (only the linux-64-cross CI path was wired up).
• On osx-arm64, a second source entry ships an upstream pre-built zig-0.15.2 tarball as an offline bootstrap. The published conda-forge zig_impl_osx-arm64 0.15.2 pins libcxx 20.* at runtime, which is mutually exclusive with the libcxx 21 compiler stack 0.16 requires. build.sh symlinks the extracted binary into PATH as ${CONDA_ZIG_BUILD}.

Build path

• CMAKE_FALLBACK: 0 → 1. The 0.15.2 bootstrap can't parse 0.16's build.zig (new fields use_new_linker, graph.io), so we invoke zig's own stage1 → zig2 → stage3 CMake bootstrap instead. Bootstrap zig is still on PATH so the CMake zigcpp step finds it, but the zig-build-with-zig attempt fails-over to the CMake path.
• cmake_install_dir → \${PREFIX}. Zig's upstream cmake/install.cmake bakes CMAKE_INSTALL_PREFIX into the generated install script via install(CODE ...), so cmake --install . --prefix X is silently ignored. We configure with the real prefix up front.
• Fixed a set -e hazard: is_debug && echo \"SUCCESS...\" as the final statement of cmake_fallback_build's success branch returned non-zero in non-debug mode, tripping set -e in the caller between cmake-install and the mv zig triplet-zig rename. Trailing || true now forces a 0 exit on the success path. Same treatment for symmetric sites in build.sh and apply_cmake_patches. Previously this was masked by leaving DEBUG_ZIG_BUILD=1 on.

Patches — common

Cleanly re-split so the two Lld patches aren't implicitly coupled:

• Lld.zig-macho-lld-support — rebased. Only MachO LLD plumbing: MachO struct, machoLink function with static libcxx linking, ZigLLDLinkMachO binding, target.zig hasLldSupport. No libcxx_shared references.
• Lld.zig-prefer-shared-libcxx — rebased. Owns every shared-libcxx change: the new src/link/libcxx_shared.zig file plus hunks in src/link/Lld.zig (COFF/ELF/WASM/machoLink) and src/link/MachO.zig. Must apply after macho-lld-support since it patches inside machoLink; the recipe order already reflects this.
• main.zig-fuse-ld-lld-cc-path — rebased. Added ld64.lld to the early lldMain dispatch and to the cmdMain LinkMachO dispatch; .other cc-path handler intercepts -fuse-ld=lld and pass-through of unrecognized linker args as -Wl,....
• Config.zig-macho-no-auto-lld, llvm.zig-lld-ofmt-macho — line-shift rebases, logic unchanged.
• zig_llvm.cpp-mingw-def-dll-suffix.patch — dropped permanently. 0.16 rewrote MinGW .def parsing in pure Zig (src/libs/mingw/def.zig) and already appends .dll to LIBRARY names without extensions.

The big API migration across the rebased Lld patches:

• std.fs.Dir.copyFile(src, s, dst, d, .{}) → Io.Dir.copyFile(..., io, .{})
• std.fs.cwd().access(path, .{}) → Io.Dir.cwd().access(io, path, .{})
• libcxx_shared.zig takes io from comp.io.

Patches — linux

• build.zig-01-maxrss, build.zig-02-doctest-forward-target — rebased (line shifts + one missed else-if hunk restored).
• llvm.zig-triple-no-glibc-version — rebased.
• link.zig-01-ldscript-relpath-and-l-flags — rebased, including migration to 0.16's Io.Dir API for directory iteration (openDir(io, ...), close(io), iter.next(io)).
• link.zig-02-default-allow-so-scripts — rebased; regenerated against the 01-applied baseline so the 3-patch stack applies correctly.
• link.zig-03-ldscript-sysroot-remap — rebased; preserves 0.16's arena.dupe + mutex.lockUncancelable(io) pattern on the no-sysroot path, falls back to it when base.comp.sysroot is not set.
• posix.zig-glibc-2.17-fstat.patch — dropped. std.posix.fstat was removed entirely in 0.16; no callers remain anywhere in the stdlib or compiler.
• Object.zig-elf-zstd-decompression.patch — dropped. Upstream 0.16 already has the .ZSTD branch (link(ELF): add ZSTD decompression support for compressed sections ziglang/zig#25107 merged).
• Elf.zig-debug-tag-bare-TODO-panics.patch — dropped. Diagnostic-only tagging from 0.15 debugging, not needed.

Recipe tests

• Re-enabled the osx -fuse-ld=lld -Wl,-exported_symbols_list test — now passes with rebased Lld patches.
• Broadened package_contents glob for lib/zig/c/ (0.16 added ctype, fcntl, malloc, math, stdlib/*.zig, sys/*.zig, etc.).
• Disabled the doc/langref.html check across all platforms for now. 0.16's stage2 hardcodes -Dno-langref (the CMake-driven bootstrap path we rely on) because @cImport is unavailable there; a proper post-install zig build langref step using stage3 is follow-up work.

Local validation

Both green end to end:

• osx-arm64 (native on M1): all 4 packages produced, 63/63 tests pass (0 failed, 8 skipped intentionally), including the rebased -fuse-ld=lld macOS/Mach-O LLD test.
• linux-aarch64 (OrbStack ubuntu:questing arm64 VM, same tree over 9P): all 4 packages produced, 62 activation tests pass, the -fuse-ld=lld --dynamic-list Linux/ELF test passes, and a chunk of zig's own behavior suite runs (skips are arch/emulation-related).

Known follow-ups not in this PR

• Windows (non_unix/*) patches still on 0.15.2 — will fail.
• ppc64le (11 arch-enablement patches against ELF internals) — will fail.
• linux-64 / linux-riscv64 / linux-s390x / osx-64 / win-arm64 variants have not been attempted locally.
• c_stdlib_version bump in this PR is only linux-aarch64; other linux variants probably need the same.
• Wire up a post-install zig build langref step using stage3 so doc/langref.html can be re-enabled in package_contents.

Test plan

• CI runs osx-arm64
• CI runs linux-aarch64
• CI runs linux-64, osx-64, win-64 (expected to fail until their patch stacks are rebased)
• Someone with a linux-ppc64le / win-arm64 / linux-s390x environment picks up the remaining patch rebases

🤖 Generated with Claude Code

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

[MementoRC]

Cool, I did look into the 2.17 and think there is a path, got linux-64 passing locally, I'll stop working on it and review this PR, add what I found. I directed my 0.15.2 work toward a new branch, this way we don't mix-up main

[MementoRC]

Hey @tdejager, great to see you working on 0.16.0! I've been doing parallel work on the same bump and hit a few issues that might save you time, especially for linux-64. I put my findings in a draft PR for reference: #102

Here are the key things I found:

1. CMAKE_FALLBACK=1 is required for the bootstrap

Zig 0.16.0's build.zig uses APIs (use_new_linker, b.graph.io) that are incompatible with the 0.15.2 bootstrap compiler. The zig build step fails, and the cmake fallback path (compiling zig2.c with the host C compiler) is needed. I set CMAKE_FALLBACK: "1" in the recipe env vars.

2. glibc 2.17 syscall stubs for zig2.c linking

The pre-generated zig2.c calls getrandom (glibc 2.25), copy_file_range (glibc 2.27), and statx (glibc 2.28) — all absent from conda-forge's glibc 2.17 sysroot. This causes undefined reference linker errors on linux-64.

Fix: recipe/building/_glibc217_syscall_stubs.sh — C stubs using syscall() with weak symbols, compiled to .o and linked into zig2 via both config.h injection (zig build path) and the CMakeLists.txt patch (cmake fallback path).

3. Drop Threaded.zig-glibc-2.17-stat-fallback.patch

This patch from 0.15.x uses linux.E.init(rc) which doesn't exist on 0.16.0's raw enum(u16) E type. More importantly, the patch isn't needed: when building with -Dtarget=x86_64-linux-gnu.2.17, zig 0.16.0 correctly sets statx_use_c=false and uses raw kernel syscalls (which work on modern CI kernels ≥ 4.11).

4. ppc64le + Windows patches regenerated

I also regenerated the ppc64le and non_unix patch stacks for 0.16.0 in #102 if those are useful for the follow-up.

---

Happy to coordinate — let me know if you'd prefer I push changes to your branch or if cherry-picking from #102 works better.

[tdejager]

Sounds good, note that I did let Claude loose mostly. Although I try to be critical to what it does.

I used osx-arm64 for local builds and a vm for linux-arm as well.

I guess the cmake fallback is something we can turn off once we have a new version bootstrapped. Not totally sure why an old version cannot be used instead though.

[tdejager]

Oh we posted at the same time, feel free to push anything you want on this. You answered 2 of my questions there :)

[tdejager]

Oh btw I see Claude added the MNRT prefix. Not sure if that means memento 😅, sorry don't mean to appropriate that one :)

[MementoRC]

@tdejager Right, I think is it intentional, from discussion with Andrew in the past he had recommended the CMake as the foolproof way of building ZIG. I think it stems from them providing bootstrap versions and have the flexibility to break version backward compatibility when needed.

The CMAKE_FALLBACK little thingy defaults to zig building zig anyway,

Do you know whether there was a change in rattler-build, all my PRs suddenly stop to build anything

[MementoRC]

@tdejager MNRT? I would rather let you continue with this PR, I posted my version just for you to have the reference code or commits - I am still struggling with the 0.15.2 libc++ dynamic library

Dropping off for a while, I'll check back later on

[tdejager]

Ah always from the phone it corrects into something silly I meant the MNT prefix.

Regarding rattler-build there has been a big release yesterday I believe. What are you encountering?

And sure I'll reference the other PR.

[tdejager]

Claude says:

Thanks @MementoRC — big timesaver. I've adopted the key pieces from #102 in 449744c:

• glibc 2.17 syscall stubs: cherry-picked your _glibc217_syscall_stubs.sh helper and the updated cmake/0001 and cmake/0002 patches. build.sh now compiles the stubs after configure_cmake_zigcpp and appends the .o to ZIG_LLVM_LIBRARIES; cmake/0002 handles the CMake-fallback path. Reverted my linux-aarch64 c_stdlib_version: 2.17 → 2.28 bump — keeps the conda-forge 2.17 baseline intact. Validated locally in OrbStack: linux-aarch64 builds end-to-end with glibc 2.17 + stubs, 62/62 activation tests pass, -fuse-ld=lld --dynamic-list (Linux/ELF) passes.

Plus two CI-only fixes I caught via cf-job-logs:

• build.sh never ran on every macOS job and the Azure linux-aarch64 job. rattler-build 0.63+ treats script: { env: {...} } (no file: or content:) as an empty inline script, whereas 0.62 fell back to recipe/build.sh. CI is on 0.63; this is why lib/zig/* was missing from every osx package. Fix: explicit file: build.sh.

• ppc64le patches were killing every linux variant. The gate was linux and (x86_64 or ppc64le), so a conda-forge linux-64 runner cross-compiling to linux-aarch64 / linux-riscv64 still applied the un-rebased ppc64le stack and died on ppc64le/0001-arch-support-Elf.zig.patch. Tightened to cross_target_platform_ == \"linux-ppc64le\". Commented out the non_unix/* block for the same reason so Windows CI at least reaches the build step.

Still untouched here, cleanly pointable at #102:

• non_unix/* rebased patches (your Windows rebases)
• ppc64le/* rebased patches (the 5 you kept + the 2 upstream-fixed drops)
• doctest-forward-target deferral

Will try and cherry-pick the rest.