go: cmd/cgo, cmd/link: with zig as CC/CXX, Go linker does not put libc onto the linker line, causing undefined symbol errors

Would you be able to link the memset/memcpy fix here? Was this recent? @motiejus

Sure, here it is: https://github.com/ziglang/zig/commit/b3f4e0d091d83874af849f1d1a2328ad7c154d42

I attempted to workaround res_search issue it in bazel-zig-cc (https://git.sr.ht/~motiejus/bazel-zig-cc/commit/7b0de33070bef14265d7ec560fca43f5e132eea4 and https://git.sr.ht/~motiejus/bazel-zig-cc/commit/8d1e1c9fa66712c8f7da3634990ab4ccd2aa47c9), but that doesn’t always work, as you can see.

We agreed with @andrewrk that we will change the offending headers in upsteam zig (add ifdefs on glibc version). To my latest knowledge, @sywhang is working on that.

zig cc follows the same static/dynamic linking rules as clang and gcc; it shares the exact same command line API. On glibc-based systems, GCC, Clang, and zig cc all link dynamically against libc.so by default:

andy@ark ~/tmp> gcc -o hello hello.c
andy@ark ~/tmp> ldd hello
	linux-vdso.so.1 (0x00007ffc9f3df000)
	libc.so.6 => /nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib/libc.so.6 (0x00007f13b9dec000)
	/nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib/ld-linux-x86-64.so.2 => /nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib64/ld-linux-x86-64.so.2 (0x00007f13b9fc3000)
andy@ark ~/tmp> clang -o hello hello.c
andy@ark ~/tmp> ldd hello
	linux-vdso.so.1 (0x00007ffd177ab000)
	libc.so.6 => /nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib/libc.so.6 (0x00007fc1ef774000)
	/nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib/ld-linux-x86-64.so.2 => /nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib64/ld-linux-x86-64.so.2 (0x00007fc1ef94b000)
andy@ark ~/tmp> zig cc -o hello hello.c
andy@ark ~/tmp> ldd hello
	linux-vdso.so.1 (0x00007fff1d5f7000)
	libc.so.6 => /nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib/libc.so.6 (0x00007ff3ec3ae000)
	/nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib/ld-linux-x86-64.so.2 => /nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123/lib64/ld-linux-x86-64.so.2 (0x00007ff3ec585000)

A typical linker line for any C compiler will look something like this:

ld -m elf_x86_64 -o hello Scrt1.o crti.o hello.o libcompiler_rt.a libm.so.6 libpthread.so.0 libc.so.6 libdl.so.2 librt.so.1 libld.so.2 libutil.so.1 libc_nonshared.a crtn.o

In this example, hello.o contains libc dependencies, but it is the linker which satisfies them by putting libc on the linker line, as you can see.

I’m not sure what you mean when you say the Go linker never links directly against the C library. Indeed, getuid and friends come from the libc.so shared C library, as you can see above, but in this issue, the Go linker is omitting libc.so from the list of objects to link, causing the undefined symbol errors.

We can simulate this same problem with any C compiler by passing -nostdlib, causing the linker driver to omit libc.so from the linker line, as Go is doing:

andy@ark ~/tmp> clang -o hello hello.c -nostdlib
/nix/store/b987cpz6k72fkp05ycbhvk635y46m3cc-binutils-2.35.2/bin/ld: /tmp/hello-d74816.o: in function `main':
hello.c:(.text+0x15): undefined reference to `printf'
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)

Ultimately, the Go toolchain is compiling C source files into object files which contain libc dependencies. If any C compiler is used to then link these together, everything works fine, because C compilers put libc onto the linker line. However, when the Go linker is used, which is the default, it does not satisfy its own dependencies.

I think one thing that would shed some light on this issue would be seeing, side by side, the Go linker line when CC=clang is used vs CC="zig cc". I spent a couple hours trying to obtain this information but did not figure out how to do it.