`-lc` doesn't link `c_nonshared`

[Vexu]

$ cat a.c
extern char __libc_single_threaded;
int main(void) {
    return __libc_single_threaded;
}
$ clang a.c
$ zig build-exe a.c -lc
ld.lld: error: undefined symbol: __libc_single_threaded
>>> referenced by a.c:3
>>>               /home/vexu/.cache/zig/o/00d791557252b46f5ed6668a930dc12a/a.o:(main)
error: LLDReportedFailure

Not sure how this works on other targets but on Arch Linux it means that building stage2 with system LLVM requires this patch:

diff --git a/build.zig b/build.zig
index 5896ab1a8..fb821ccf4 100644
--- a/build.zig
+++ b/build.zig
@@ -550,6 +550,7 @@ fn addCmakeCfgOptionsToExe(
                 else => |e| return e,
             };
             exe.linkSystemLibrary("unwind");
+            exe.linkSystemLibrary("c_nonshared");
         } else if (exe.target.isFreeBSD()) {
             try addCxxKnownPath(b, cfg, exe, "libc++.a", null, need_cpp_includes);
             exe.linkSystemLibrary("pthread");

[daurnimator]

Arch uses glibc 2.35.

Looking through recent glibc changes related to c_nonshared I found bminor/glibc@1a2f44a. I wonder if this means that linking pthread previously implied c_nonshared, but it doesn't any more.

[ifreund]

The proper fix is probably adding -lc_nonshared to libcFullLinkFlags() in src/target.zig if targeting glibc. I would like to understand exactly what's happening here though before doing that.

[matu3ba]

At least for me a default build of glibc contains libc_nonshared.a, but srcglibc.zig` does not contain it in the library list:

// The order of the elements in this array defines the linking order.
pub const libs = [_]Lib{
    .{ .name = "m", .sover = 6 },
    .{ .name = "pthread", .sover = 0 },
    .{ .name = "c", .sover = 6 },
    .{ .name = "dl", .sover = 2 },
    .{ .name = "rt", .sover = 1 },
    .{ .name = "ld", .sover = 2 },
    .{ .name = "util", .sover = 1 },
};

Nevertheless, libc_nonshared.a is generated during building stage1.

How is Zig picking up the correct paths to the libcs etc in .cache? rg glibc inside the build folder of stage1 shows no results. Is the path picked up from calculating/combining some hashes?

[andrewrk]

Note that zig is perfectly capable of providing libc_nonshared.a... but in the case of native builds we don't do it because we want to actually integrate with system libc. So we're stuck figuring out what the various systems want from us.

[ifreund]

On my glibc 2.32 void linux system /usr/lib/libc.so appears to be a linker script which pulls in libc_nonshared.a:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED ( /usr/lib64/ld-linux-x86-64.so.2 ) )

This might help explain things, in particular why I wasn't seeing any reference to libc_nonshared.a in gcc -v output on my system.

[BratishkaErik]

Ok, on my glibc 2.35 gentoo system cat /usr/lib/libc.so:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.2 ) )

cat /usr/lib64/libc.so:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )

[matu3ba]

On Arch its similar
cat /usr/lib/libc.so

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) )

cat /usr/lib64/libc.so

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) )

file /usr/lib/ld-linux.so.2 symlinking to /usr/lib32/ld-linux.so.2 should not make a difference in this context.