zig: re-enable static llvm

[dotcarmen]

After #209803 was merged, users (including myself) started experiencing the issue described by #210073

I also added a test to ensure that zig version works as intended to prevent future similar breakages

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

fixes #210073

[github-actions]

Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

[SMillerDev]

Can't we dynamically link libc++ like the error suggests? Our docs outline why we want to avoid this: https://docs.brew.sh/Acceptable-Formulae#shared-vs-static-libraries

[dotcarmen]

i can look into it, but i'm afraid i won't get to it for another week and a half or so (i'm currently traveling and debugging linker errors isn't the most fun thing to do 😅)

this patch immediately unblocks users, despite the less-than-ideal solution - up to yall if you want to accept or reject the patch in the meantime :)

[gromgit]

Are users actually "blocked" right now? The formula's test block successfully compiles and runs an actual program, so unless there are issues with the current formula along the lines of "zig fails to compile a correct program", I agree with @SMillerDev that it would be better to take the necessary time to resolve this the way zig itself says to.

[cho-m]

The problem is it breaks Linux due to dynamic liblld so -DZIG_SHARED_LLVM=ON is needed there.

You could try setting shared on Linux and static on macOS.

---

Taking a look at Zig's build, it looks like issue is that upstream is always statically linking a bundled libc++.a / libc++abi.a on macOS, i.e.:

• https://github.com/ziglang/zig/blob/0.14.0/build.zig#L787-L788

              .ios, .macos, .watchos, .tvos, .visionos => {
                  mod.link_libcpp = true;

• https://github.com/ziglang/zig/blob/0.14.0/src/link/MachO.zig#L450-L455

      // libc++ dep
      if (comp.config.link_libcpp) {
          try system_libs.ensureUnusedCapacity(2);
          system_libs.appendAssumeCapacity(.{ .path = comp.libcxxabi_static_lib.?.full_object_path });
          system_libs.appendAssumeCapacity(.{ .path = comp.libcxx_static_lib.?.full_object_path });
      }

It was reported by MacPorts with the most accurate analysis being ziglang/zig#20450 (comment) but upstream didn't look into further.

Linux won't hit same issue as it uses GCC libstdc++

• https://github.com/ziglang/zig/blob/0.14.0/CMakeLists.txt#L132

      set(ZIG_SYSTEM_LIBCXX "stdc++" CACHE STRING "system libcxx name for build.zig")