zig version on 0.13 built with MacPorts spits warning about incorrect linkage

[i0ntempest]

Zig Version

0.13.0

Steps to Reproduce and Observed Behavior

zig version gives

0.13.0
error: Zig was built/linked incorrectly: LLVM and Clang have separate copies of libc++
       If you are dynamically linking LLVM, make sure you dynamically link libc++ too

The binary is built from this portfile: macports/macports-ports#24430

Expected Behavior

The compiler seems to work fine, but I would expect a more useful warning message than this. I don't know if this is triggered by how MacPorts installs LLVM and Clang. What do I need to do to get rid of this warning?

[i0ntempest]

Hello? Anyone can help out here?

[alexrp]

Best guess is that they're linking libc++ into LLVM/Clang statically, while the Zig compiler links to it dynamically, but it's hard for us to really know. Bottom line is that you somehow have two libc++ libraries loaded into the Zig compiler process, and it will cause arbitrary breakage when things that should compare equal don't.

[i0ntempest]

I noticed the zig binary has rpath style links to llvm libraries:

$ otool -L /opt/local/bin/zig 
/opt/local/bin/zig:
	@rpath/libclang-cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libLLVM.dylib (compatibility version 1.0.0, current version 18.1.7)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.1)
	/opt/local/lib/libzstd.1.dylib (compatibility version 1.0.0, current version 1.5.6)
	/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libxml2.2.dylib (compatibility version 15.0.0, current version 15.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2)

I have multiple llvm/clang versions on my system but the binary only has llvm18 in its rpaths:

otool -l /opt/local/bin/zig | grep -i path
          cmd LC_RPATH
         path /opt/local/libexec/llvm-18/lib (offset 12)
          cmd LC_RPATH
         path /opt/local/libexec/llvm-18/lib (offset 12)
          cmd LC_RPATH
         path /opt/local/libexec/llvm-18/lib (offset 12)
          cmd LC_RPATH
         path /opt/local/lib (offset 12)
         name @rpath/libclang-cpp.dylib (offset 24)
         name @rpath/libLLVM.dylib (offset 24)

Does this indicate possible linkage problems?

[alexrp]

You would need to find out if that libLLVM.dylib or libclang-cpp.dylib has its own statically-linked copy of libc++. (I'm not familiar enough with macOS to suggest how, unfortunately.)

[i0ntempest]

I've checked and both of them dynamically links to /usr/lib/libc++.1.dylib so I don't think they're statically linking libc++. @ryandesign @reneeotten Can you please take a look at this?

[alexrp]

At that point, it might be the Zig compiler itself that has statically linked libc++. That actually seems more likely, looking at the otool output above. I have no idea how that would have happened, though.

Maybe you can check if it has internal libc++ symbols or something?

[kencu]

this issue may have been fixed by

macports/macports-ports@a1d4865

macports previously built and installed a new copy of libc++.dylib in a default directory specified by llvm.

This new copy of libc++.dylib was often found opportunistically.

The new copy of libc++.dylib is now tucked into a subdirectory, so it is found only if specifically added.

[i0ntempest]

I made sure I have only v18 of llvm and clang active on my system and rebuilt zig, but nope. The new binary still gives the error.

[andrewrk]

This must be fixed by macports. There is nothing for Zig project to do.

[cho-m]

At that point, it might be the Zig compiler itself that has statically linked libc++. That actually seems more likely, looking at the otool output above. I have no idea how that would have happened, though.

This sounds right given bundled libc++.a and libc++abi.a is always used:

zig/build.zig

Lines 787 to 788 in 4cefd1b

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

zig/src/link/MachO.zig

Lines 450 to 455 in 4cefd1b

	// 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 });
	}

---

There doesn't seem to be an easy way of enabling shared LLVM on macOS that doesn't result in conflict warning.

The workaround would be patching build.zig to change above line and force linkage to correct libc++. It gets rid of conflict warning but no idea if this breaks something else.

[giftkugel]

Got the same message today on my Mac after brew upgrade updated zig from 0.13.0 to 0.14.0

> zig version
0.14.0
error: Zig was built/linked incorrectly: LLVM and Clang have separate copies of libc++
       If you are dynamically linking LLVM, make sure you dynamically link libc++ too

[alexrp]

#23127

[onion108]

Got the same message today on my Mac after brew upgrade updated zig from 0.13.0 to 0.14.0

zig version
0.14.0
error: Zig was built/linked incorrectly: LLVM and Clang have separate copies of libc++
If you are dynamically linking LLVM, make sure you dynamically link libc++ too

so do i

[carlocab]

Should be fixed by #23264. See discussion at Homebrew/homebrew-core#210173.