darwin compiler-rt symbols are not exported as weak #31844

Zig Version

0.16.0-dev.3061+9b1eaad13

Steps to Reproduce and Observed Behavior

on Darwin aarch64:

~/c/g/z/z/gna (master)> ./zig-aarch64-macos-0.16.0-dev.3061+9b1eaad13/zig build-lib -fcompiler-rt -fllvm ../gna.zig -femit-bin=gna.a
~/c/g/z/z/gna (master)> nm -m gna.a | grep ctz
00000000000004e0 (__TEXT,__text) private external ___ctzdi2
0000000000000578 (__TEXT,__text) private external ___ctzsi2
0000000000000410 (__TEXT,__text) private external ___ctzti2
00000000000004e0 (__TEXT,__text) non-external _compiler_rt.count0bits.__ctzdi2
0000000000000578 (__TEXT,__text) non-external _compiler_rt.count0bits.__ctzsi2
0000000000000410 (__TEXT,__text) non-external _compiler_rt.count0bits.__ctzti2

Previously, symbols from compiler-rt were exported as WEAK as the code suggests:

pub inline fn symbol(comptime func: *const anyopaque, comptime name: []const u8) void {
 @export(func, .{ .name = name, .linkage = linkage, .visibility = visibility });
}
....
pub const linkage: std.builtin.GlobalLinkage = if (builtin.is_test)
 .internal
else if (ofmt_c)
 .strong
else
 .weak;

This is important for us as we have link against custom override of such symbols.
This seems to impact only darwin.

Expected Behavior

~/c/g/z/z/gna (master)> ./zig-aarch64-macos-0.16.0-dev.3041+3dc5f1398/zig build-lib -fcompiler-rt -fllvm ../gna.zig -femit-bin=gna.a
~/c/g/z/z/gna (master)> nm -m gna.a | grep ctz
00000000000004e0 (__TEXT,__text) weak private external ___ctzdi2
0000000000000578 (__TEXT,__text) weak private external ___ctzsi2
0000000000000410 (__TEXT,__text) weak private external ___ctzti2

As showed, the same command produced weak symbols on a prior nightly.

@mlugg I suspect this is related to your LLVM backend changes?

Likely due to weak aliases which according to the commit history have been causing problems of this nature for some time:

commit 59acfb12635b79fd83950eed10172cf43694b978
Author: Andrew Kelley <andrew@ziglang.org>
Date: Fri Jan 17 12:53:25 2025 -0800
 compiler_rt: don't rely on weak aliases
commit f46567e6bf80c4f5b21608383bf99cca8a77c3b0
Author: Andrew Kelley <andrew@ziglang.org>
Date: Mon Dec 5 21:00:01 2022 -0700
 CI: update tarballs
 
 In particular, these two changes are relevant:
 
 * zig cc: support -stack in addition to --stack for linker arg
 - Fixes stack overflow when running zig2 on aarch64-macos.
 * compiler_rt: avoid using weak aliases
 - Fixes duplicate symbol when linking zig2 on aarch64-linux.
commit 2c49a6c1909e7ea17af5fb7d43adef45d7125473
Author: Andrew Kelley <andrew@ziglang.org>
Date: Mon Dec 5 14:52:21 2022 -0700
 compiler_rt: avoid using weak aliases
 
 This is a partial revert of 0d533433e21621177fb291e2a4901bee11834501,
 which regressed this behavior. The idea here is to avoid aliases, which
 happens when the same function is exported with multiple names. The
 problem with aliases is that weak aliases don't seem to work, causing
 symbol collisions when multiple of the same symbol are provided, despite
 the desired behavior that weak symbols are overridden.
 
 In this case we export redundant functions with different names. Thanks
 to -ffunction-sections, the unused functions will be garbage-collected
 at link time. This leaves us with the best of both worlds: Zig's
 compiler-rt will provide both sets of symbols, and it will be
 binary-compatible with different compilers that expect different names,
 while still resulting in binaries without garbage.
 
commit cd019ee502d6792c1615b0fab10827db419beab4
Author: Andrew Kelley <andrew@ziglang.org>
Date: Sun May 8 13:06:21 2022 -0700
 compiler_rt: avoid weak aliases on Windows
 
 When exporting math functions for Windows, we provide weak exports of
 'l' variants rather than weak aliases. We still use aliases on other
 operating systems so that the 'l' variants have one less jump
 instruction in this case.

Assuming it is due to weak aliases (which it probably is), let's try to get this fixed in upstream LLVM. The first step will be checking whether this is still a problem in LLVM 22, since it's possible (though unlikely) that they already fixed it.

Still broken on LLVM 22. Upstream bug filed at https://github.com/llvm/llvm-project/issues/196047.