static zig libraries are exporting getauxval which is overriding libc symbol

[vesim987]

Zig Version

0.12.0-dev.2589+eaa6218f0

Steps to Reproduce and Observed Behavior

Currently https://github.com/ziglang/zig/blob/master/lib/std/os/linux.zig#L391-L404 is exporting getauxvec when not linking libc, which is causing static libraries to export such symbol, and overriding the one from libc. This is causing getauxvec to return zero which is breaking https://github.com/ziglang/zig/blob/master/lib/std/start.zig#L478-L479

Repro: https://github.com/vesim987/zig-getauval-repro

$ zig build run
thread 134272 panic: cast causes pointer to be null
/nix/store/ggiv642mg6v4x34kmkk8xk5cv2kxygwk-zig-0.12.0-dev.2589+eaa6218f0/lib/std/start.zig:480:41: 0x1039bd5 in main (exe)
        const phdrs = (@as([*]elf.Phdr, @ptrFromInt(at_phdr)))[0..at_phnum];

Expected Behavior

The code about should work w/o any iisues.
TBH i don't really know what the correct behavior should be, maybe exporting this symbol only when builtin.output_mode == .Exe?

[rootbeer]

I can reproduce the problem (nice minimal repro, btw).

If I link the library against libc, everything seems to work:

@@ -10,6 +10,7 @@ pub fn build(b: *std.Build) !void {
         .target = target,
         .optimize = optimize,
     });
+    lib.linkLibC();

     const exe = b.addExecutable(.{
         .name = "exe",

I believe its reasonable for Zig to require all the libraries built and linked into an executable to be targeting the "same" libc-or-not. But I don't have any insight into Zig's actual plans here. Do you expect to be able to mix and match libc-or-not in your use case?

That said, the failure in this case seems like a bug either way. I would expect either Zig to fail the link if the configured components are not supported together. Or the generated binary should work. A broken binary shouldn't be generated.

(BTW, your description uses getauxvec in a couple places, where I'm pretty sure you mean getauxval.)

[Cloudef]

This definitely should be fixed so that its only exported when output mode is exe (and maybe shared lib?), creating freestanding static libs that dont depend on libc becomes pretty annoying otherwise

[kcbanner]

Related issue to consider when fixing this: #16281