feat: Zig 0.16.0 compatibility

[gilbertwong96]

Updates the Zig wrapper to compile and run on Zig 0.16.0.

Zig 0.16.0 API changes:

• std.c.stat → Io.Dir.cwd().statFile (cross-compile fix)
• Permissions.unixNew → Permissions.fromMode
• Guard Permissions.toMode() on Windows (enum, no POSIX mode bits)
• Drop unused arena parameter from maybe_install_musl_runtime

Process spawning:

• Replace std.process.replace with spawn + child.wait (replace hangs on macOS arm64 in 0.16.0)
• Unify Windows/Unix code paths

Bug fixes:

• Split "-elixir ansi_enabled true" and "-s elixir start_cli" into separate argv entries — passing them as single strings caused the BEAM to hang in __select on macOS
• EPIPE hang when piping output to head/less. When stdout is piped to a command that exits early, the BEAM's standard_io group leader crashes on EPIPE and the VM hangs indefinitely trying to flush IO during shutdown. The wrapper now pipes child stdout through itself via a copy thread; when the downstream pipe breaks (EPIPE on write), the copy thread kills the child process, allowing the wrapper to exit cleanly instead of blocking on child.wait() forever.

CI:

• Add Zig 0.16.0 + macOS arm64 (macos-14) to cross-build matrix

Builds on #224 by @jsmestad. Closes #221.

[jsmestad]

Any reason you dropped support for glibc and went musl only?

[gilbertwong96]

Any reason you dropped support for glibc and went musl only?

Yeah, this branch still contains non-sense change for debug and test purposes, I will sort out branch to remove non sense changes and then force push them.

[gilbertwong96]

Force pushed

[doawoo]

I'll have to update the runner jobs for this, but it's looking good to me. Let me run a few tests offline and then I'll merge and update CI to be correct lol

[joshrotenberg]

Tested this branch on macOS 26.5 (Tahoe) / Apple Silicon with zig 0.16.0. Packaging works: it builds a self-contained binary that boots the BEAM with no Elixir on PATH. Thanks for tackling this.

One regression: elixir:start_cli/0 now runs and consumes the application's CLI arguments.

Minimal repro, a burrito app that just prints what it sees:

# lib/argv_probe/application.ex
def start(_type, _args) do
  IO.puts(:stderr, "running_standalone? = #{Burrito.Util.running_standalone?()}")
  IO.puts(:stderr, "get_arguments()     = #{inspect(Burrito.Util.Args.get_arguments())}")
  Supervisor.start_link([], strategy: :one_for_one, name: ArgvProbe.Sup)
end

Built with this branch and run:

$ ./argv_probe hello world
running_standalone? = true
get_arguments()     = ["hello", "world"]     # the app receives args correctly
No file named hello                          # ...but start_cli also runs, treats "hello" as a script
# exit 1

So argument delivery is fine (get_arguments/0 returns them, __BURRITO is set). The problem is that elixir:start_cli/0 executes and interprets the same -extra plain arguments (which Burrito.Util.Args.get_arguments/0 reads via :init.get_plain_arguments/0) as Elixir CLI arguments, then halts the VM. --version prints the Erlang/Elixir banner; any other first argument becomes "No file named ".

This traces to the -s elixir start_cli change in src/erlang_launcher.zig. In 1.5.0 it was a single argv token, so start_cli never actually ran and the app's own arg-reading was the only consumer. Split into -s, elixir, start_cli, it runs for real. The split does fix the macOS boot hang, so this looks like a side effect rather than a reason to drop it. Happy to test any patch on this macOS 26 host.

[doawoo]

@joshrotenberg Thanks for testing this out, and reporting the regression there... I'll try and look into that

[gilbertwong96]

Hi, @doawoo, push one more commit to fix the bug EPIPE hang when piping output to head/less.

[doawoo]

@gilbertwong96 Thank you for this massively helpful contribution! All tests look good!

[gilbertwong96]

Will appreciate it if you publish a new release on hex.pm :)

[doawoo]

Released!