zig 0.14.0: re-enable static llvm for macos only #210173

utox39 · 2025-03-07T20:02:37Z

Hello there 👋
as suggested by #210107 (comment) (@cho-m thanks), I implemented this workaround to fix #210073

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>?

carlocab · 2025-03-10T07:02:11Z

Formula/z/zig.rb

+    if OS.linux?
+      args = ["-DZIG_SHARED_LLVM=ON"]
+    elsif OS.mac?
+      args = ["-DZIG_STATIC_LLVM=ON"]


This likely just silences the warnings, and doesn't fix the underlying issue. Note that we still have dynamic linkage to LLD:

==> brew linkage --cached zig System libraries: /usr/lib/libSystem.B.dylib /usr/lib/libxml2.2.dylib /usr/lib/libz.1.dylib Homebrew libraries: /opt/homebrew/opt/lld/lib/liblldCOFF.dylib (lld) /opt/homebrew/opt/lld/lib/liblldCommon.dylib (lld) /opt/homebrew/opt/lld/lib/liblldELF.dylib (lld) /opt/homebrew/opt/lld/lib/liblldMachO.dylib (lld) /opt/homebrew/opt/lld/lib/liblldMinGW.dylib (lld) /opt/homebrew/opt/lld/lib/liblldWasm.dylib (lld) /opt/homebrew/opt/z3/lib/libz3.4.14.dylib (z3) /opt/homebrew/opt/zstd/lib/libzstd.1.dylib (zstd)

And LLD itself links dynamically to libLLVM and libc++:

❯ brew linkage lld System libraries: /usr/lib/libSystem.B.dylib /usr/lib/libc++.1.dylib /usr/lib/libz.1.dylib Homebrew libraries: /opt/homebrew/Cellar/lld/19.1.7/lib/liblldCOFF.dylib (lld) /opt/homebrew/Cellar/lld/19.1.7/lib/liblldCommon.dylib (lld) /opt/homebrew/Cellar/lld/19.1.7/lib/liblldELF.dylib (lld) /opt/homebrew/Cellar/lld/19.1.7/lib/liblldMachO.dylib (lld) /opt/homebrew/Cellar/lld/19.1.7/lib/liblldMinGW.dylib (lld) /opt/homebrew/Cellar/lld/19.1.7/lib/liblldWasm.dylib (lld) /opt/homebrew/opt/llvm/lib/libLLVM.dylib (llvm) /opt/homebrew/opt/zstd/lib/libzstd.1.dylib (zstd)

So the problem of loading possibly conflicting versions of libc++ remains. To add to that, this also introduces the possibility of loading conflicting versions of libLLVM. One version is the one that is statically linked, and the other is the one loaded by LLD.

The only real fix here is to allow zig itself to link dynamically to the system libc++ instead of forcing linkage to a bundled static version.

I understand, but as I have already specified this is only a workaround and, from some research I have done, this would seem to be a long-standing problem and not yet solved or at least made known to zig itself (https://ziggit.dev/t/linking-stage3-zig-dynamically-with-system-libc/5726).

I have also seen how Macports solves this problem and they too have implemented the same workaround:

# We need to link LLVM statically until a way is found to force zig to link the system libc++ dynamically. configure.args-append -DZIG_STATIC_LLVM=ON

(https://github.com/macports/macports-ports/blob/master/lang/zig/Portfile)

would seem to be a long-standing problem and not yet solved or at least made known to zig itself

Can you report it to Zig then and see what their opinion is on the fix?

I understand the temptation to blindly follow what MacPorts does here, but their workaround is not applicable for us.

MacPorts almost certainly does not ship shared libraries for LLD, and so Zig can only link with the static versions. That makes using ZIG_STATIC_LLVM somewhat safe, because the static libraries will not load a different libLLVM or libc++.

However, we do not ship the LLD static libraries, and only ship the shared ones. As a consequence, using ZIG_STATIC_LLVM here will still result in your loading two different versions of libc++ (and possibly two different versions of libLLVM). This is not safe, and is exactly what the warning you're currently seeing is about.

would seem to be a long-standing problem and not yet solved or at least made known to zig itself

Can you report it to Zig then and see what their opinion is on the fix?

@SMillerDev I just reported to zig: ziglang/zig#23189.
Let's hope to get an answer as soon as possible but I don't think there will be a definitive answer given these discussions:
ziglang/zig#23127
ziglang/zig#20450

That's why, in general, we aren't putting a ton of energy into solving build system problems that we only have because of these dependencies that are going away ~soon.

Just want to add that I don't endorse this statement. Zig 0.14.0 has these build dependencies so of course we provide support for building Zig 0.14.0 from source with these dependencies.

suggesting to use the system-provided libc++. My suggestion is to use system-provided libc++ for Zig

When I looked into this, build.zig didn't allow linking to system libc++ on macOS (ziglang/zig#20450 (comment)).

mod.link_libcpp = true (and mod.linkSystemLibrary("c++", .{});) link the bundled libc++.a, which is visible in logs when building with -DZIG_EXTRA_BUILD_ARGS=--verbose;--verbose-link, e.g. (with some flags collapsed into "..." for readability)

zig ld -dynamic ... /private/tmp/zig-20250310-85901-s26rpz/zig-0.14.0/.brew_home/.cache/zig/o/cca824b2aab7464b1756af7de768c750/libc++abi.a /private/tmp/zig-20250310-85901-s26rpz/zig-0.14.0/.brew_home/.cache/zig/o/99e1bde16b10b2d011b5699a7950446d/libc++.a -lSystem /private/tmp/zig-20250310-85901-s26rpz/zig-0.14.0/.brew_home/.cache/zig/o/97f38acba6b985c89ced83ebbb2c47bc/libcompiler_rt.a

A quick hack I tried was patching mod.link_libcpp = true with something like test/link/macho.zig¹ but this won't be correct if LLVM was linked to another libc++:

const sdk = std.zig.system.darwin.getSdk(b.allocator, target) orelse @panic("TODO"); mod.addObjectFile(.{ .cwd_relative = b.pathJoin(&.{ sdk, "/usr/lib/libc++.tbd" }) });

zig ld -dynamic ... -l /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libc++.tbd -F /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks -lSystem /private/tmp/zig-20250310-87312-6ve6bc/zig-0.14.0/.brew_home/.cache/zig/o/517cf93ff71df00c42dced7336ddd8e2/libcompiler_rt.a

❯ otool -L /opt/homebrew/opt/zig/bin/zig | grep libc /opt/homebrew/opt/llvm/lib/libclang-cpp.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.105.0) ❯ zig version 0.14.0

Footnotes

https://github.com/ziglang/zig/blob/master/test/link/macho.zig#L886 ↩

My suggestion is to use system-provided libc++ for Zig, LLD, Clang, and LLVM.

We'd love to do that, and that's exactly what we've been trying to do in the first place. Unfortunately there does not appear to be a way to tell Zig to use the system-provided libc++ without hacking up the source.

See also ziglang/zig#23189.

Please take this patch from @mikdusan for a spin with shared LLVM/LLD: ziglang/zig#23264

Would be nice if someone could also ping the relevant folks from MacPorts.

Thanks; have opened #211129. Have also left a link to ziglang/zig#23264 at ziglang/zig#20450 and macports/macports-ports#24430 for the MacPorts folks.

carlocab

I really don't think this is a good idea. See #210173 (comment).

theKnightsOfRohan · 2025-03-12T01:13:57Z

I really don't think this is a good idea. See #210173 (comment).

As a stopgap, would it be a good idea to make zig 13.0 still available in brew? Because in the meantime, this issue would seriously hamper installing new versions of zig, and it took some time to fix this when homebrew auto-updated.

Tochemey · 2025-03-15T14:49:25Z

Hello good people, please what is the way forward? Should perform a source-based installation or is there a way to just rollback to 0.13 using brew?

Closes #210173 Fixes #210073

zig 0.14.0: re-enable static llvm for macos only

8c652a2

carlocab reviewed Mar 10, 2025

View reviewed changes

utox39 requested a review from carlocab March 10, 2025 10:38

carlocab requested changes Mar 10, 2025

View reviewed changes

theKnightsOfRohan mentioned this pull request Mar 11, 2025

Add the ability to dynamically link the system libc++ when installing Zig with a package manager on macOS ziglang/zig#23189

Open

carlocab added a commit that referenced this pull request Mar 16, 2025

zig: fix linkage with libc++

1f8a20e

Closes #210173 Fixes #210073

This was referenced Mar 16, 2025

zig: fix linkage with libc++ #211129

Merged

zig version on 0.13 built with MacPorts spits warning about incorrect linkage ziglang/zig#20450

Closed

zig: update to 0.13.0 macports/macports-ports#24430

Closed

BrewTestBot closed this in #211129 Mar 17, 2025

utox39 deleted the zig-0-14-0-macos-static-llvm branch March 17, 2025 01:09

carlocab mentioned this pull request Mar 17, 2025

macos stage3: add link support for system libc++ ziglang/zig#23264

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

zig 0.14.0: re-enable static llvm for macos only #210173

zig 0.14.0: re-enable static llvm for macos only #210173

Uh oh!

utox39 commented Mar 7, 2025

Uh oh!

carlocab Mar 10, 2025 •

edited

Loading

Uh oh!

utox39 Mar 10, 2025

Uh oh!

SMillerDev Mar 10, 2025

Uh oh!

carlocab Mar 10, 2025

Uh oh!

utox39 Mar 10, 2025

Uh oh!

andrewrk Mar 10, 2025

Uh oh!

cho-m Mar 10, 2025 •

edited

Loading

Uh oh!

carlocab Mar 10, 2025 •

edited

Loading

Uh oh!

alexrp Mar 16, 2025

Uh oh!

carlocab Mar 16, 2025

Uh oh!

carlocab left a comment

Uh oh!

theKnightsOfRohan commented Mar 12, 2025

Uh oh!

Tochemey commented Mar 15, 2025

Uh oh!

Uh oh!

Uh oh!

zig 0.14.0: re-enable static llvm for macos only #210173

zig 0.14.0: re-enable static llvm for macos only #210173

Uh oh!

Conversation

utox39 commented Mar 7, 2025

Uh oh!

carlocab Mar 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

utox39 Mar 10, 2025

Choose a reason for hiding this comment

Uh oh!

SMillerDev Mar 10, 2025

Choose a reason for hiding this comment

Uh oh!

carlocab Mar 10, 2025

Choose a reason for hiding this comment

Uh oh!

utox39 Mar 10, 2025

Choose a reason for hiding this comment

Uh oh!

andrewrk Mar 10, 2025

Choose a reason for hiding this comment

Uh oh!

cho-m Mar 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

carlocab Mar 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexrp Mar 16, 2025

Choose a reason for hiding this comment

Uh oh!

carlocab Mar 16, 2025

Choose a reason for hiding this comment

Uh oh!

carlocab left a comment

Choose a reason for hiding this comment

Uh oh!

theKnightsOfRohan commented Mar 12, 2025

Uh oh!

Tochemey commented Mar 15, 2025

Uh oh!

Uh oh!

carlocab Mar 10, 2025 •

edited

Loading

cho-m Mar 10, 2025 •

edited

Loading

carlocab Mar 10, 2025 •

edited

Loading