zig cc: detect -static and treat -l options as static library names

[ghost]

So I'm not sure if I'm doing something incorrectly, but I can't really figure out, so I came with this reproducible example.
Consider we have a C file:

#include <stdio.h>
int main()
{
    printf("Hello World!\n");
}

We want to build it for arm-linux-musleabi as a static binary and link to libressl, so we do this:

wget https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.0.tar.gz
tar xvf libressl-3.1.0.tar.gz
cd libressl-3.1.0

export CC="zig cc -target arm-linux-musleabi -static"

./configure --host=arm-linux-musleabi --disable-shared --prefix=/some/dir

make -j16 -C crypto
make -j16 -C ssl
make -j16 -C crypto install
make -j16 -C ssl install

After that we build our C file:

zig cc -target arm-linux-musleabi -I/path/to/libressl-3.1.0/include/openssl \
-L/some/dir/lib -lssl -lcrypto -static hello.c

ldd tells that it's in fact not a dynamic binary:

$ ldd hello
        not a dynamic executable

But if we try to run file on it:

$ file hello
hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-arm.so.1, not stripped

Or even if we do strings hello, /lib/ld-musl-arm.so.1 will be there too.
And we won't be able to run it on any ARM-based machine which doesn't have that file:

$ qemu-arm ./hello
/lib/ld-musl-arm.so.1: No such file or directory

(Maybe I just used some compiler options incorrectly, but I'm not really experienced with C compiler arguments)

[ghost]

Also, on an unrelated note - is it possible to do "--strip" (like in zig build-exe) with zig cc?

[andrewrk]

Also, on an unrelated note - is it possible to do "--strip" (like in zig build-exe) with zig cc?

--strip (like in zig build-exe) is enabled by default for zig cc, and turns off if you pass -g or other similar debug options.

For the other problem-

I looked through the code a bit and I believe the problem is -lssl and -lcrypto making zig think you are dynamic linking against those libraries. So this is a missing feature of zig cc, to detect -static and make it look for .a files instead.

If you are looking for a workaround in the meantime, it is to pass the .a files as positional arguments instead of -l parameters.

[ghost]

@andrewrk I'm not sure if I'm doing something wrong but it doesn't seem like strip is enabled by default, with the same C file:

#include <stdio.h>
int main()
{
    printf("Hello World!\n");
}

$ zig cc -target x86_64-linux-musl -static -O3 hello.c

$ file file hello                                                                                                                                                                           
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

$ du -sh hello
12K     hello

$ strip hello

$ du -sh hello
8.0K    hello

$ file hello                                                                                                                                                                           
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

[andrewrk]

Is that different than zig build-exe though? The strip functionality is not fully implemented; currently it only omits debug info.

[makew0rld]

Not sure if this is the same issue, but zig cc has the same problem with -Wl,-Bstatic which sets all the -l libs after it as statically linked. They end up being dynamically linked anyway. This happens without -static being specified. Running the same command with clang doesn't have this issue.

Edit: Also, Zig doesn't even seem to know the options:

warning: unsupported linker arg: -Bstatic
warning: unsupported linker arg: -Bdynamic

[SoftwareApe]

Facing the same issue as @makeworld-the-better-one, also doesn't work when using lld as a linker.

[nuald]

As @andrewrk suggested, there is a workaround by using object files (addObjectFile method), i.e.

const exe = b.addExecutable("exe", null);
exe.addObjectFile("/path/to/a-file");

[YugoCode]

Could someone please provide a workaround for using zig cc instead of zig build?

I tried following command, but still get error: undefined symbol for every libcurl function:

zig cc main.c web/https.c helper/helper.c utils/json/cJSON.c -I. -L/usr/local/lib /usr/local/lib/libcurl.a /usr/local/lib/libmbedcrypto.a /usr/local/lib/libmbedtls.a /usr/local/lib/libmbedx509.a -static

This command builds without a problem:

gcc main.c web/https.c helper/helper.c utils/json/cJSON.c -I. -L/usr/local/lib -lcurl -lmbedcrypto -lmbedtls -lmbedx509

[polarathene]

UPDATE: I misunderstood this issue:

• -static is not recognized by zig cc, it doesn't complain about it when provided like some other options do with error: Unknown Clang option. This issue is asking for zig cc to detect and handle -static properly.
• As shown below when providing the static *.a libraries explicitly as a suggested workaround above, Zig is still configuring a dynamic linker / interpreter which is causing the segfault?

---

I looked through the code a bit and I believe the problem is -lssl and -lcrypto making zig think you are dynamic linking against those libraries. So this is a missing feature of zig cc, to detect -static and make it look for .a files instead.

If you are looking for a workaround in the meantime, it is to pass the .a files as positional arguments instead of -l parameters.

Just building the hello world example without any -l parameters still ignores -static for a glibc (-gnu) target:

hello.c:

#include <stdio.h>
int main()
{
    printf("Hello World!\n");
}

# zig 0.11.0 (Aug 2023) via Fedora 40 Docker image:

$ zig cc -static -o hello hello.c
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
$ ldd hello
        linux-vdso.so.1 (0x00007fff22ad0000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f59ddc91000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f59dde83000)

# Explicit target, same output except for `GNU/Linux 2.0.0`:
$ zig cc -static -target x86_64-linux-gnu -o hello hello.c
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, with debug_info, not stripped

# Musl target is static, unlike glibc/gnu:
$ zig cc -static -target x86_64-linux-musl -o hello hello.c
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped
$ ldd hello
        not a dynamic executable

I imagine that's the actual issue here?

---

UPDATE: Nevermind, I understand the advice/discussion now 😅

To successfully static link the hello world on a -gnu target, you need to reference the absolute path for libc.a, which then fails with:

LLD Link... ld.lld: error: undefined symbol: _Unwind_Resume
>>> referenced by iofputs.o:(_IO_fputs.cold) in archive /usr/lib64/libc.a
>> referenced by fileops.o:(_IO_new_file_underflow.cold) in archive /usr/lib64/libc.a
>> referenced by wfileops.o:(_IO_wfile_underflow.cold) in archive /usr/lib64/libc.a
>> referenced 4 more times

ld.lld: error: undefined symbol: __gcc_personality_v0
>>> referenced by iofputs.o:(DW.ref.__gcc_personality_v0) in archive /usr/lib64/libc.a

So you need to also reference libgcc_eh.a explicitly too.

On fedora these can be found:

# Find a package that provides this file, in this case it's `gcc`:
$ dnf provides *gcc_eh.a
gcc-14.0.1-0.7.fc40.x86_64 : Various compilers (C, C++, Objective-C, ...)
Repo        : @System
Matched from:
Other       : *gcc_eh.a

# Query the package for the actual install path:
$ dnf repoquery -l gcc | grep gcc_eh.a
/usr/lib/gcc/x86_64-redhat-linux/14/32/libgcc_eh.a
/usr/lib/gcc/x86_64-redhat-linux/14/libgcc_eh.a

# Same process for `libc.a`:
$ dnf provides *libc.a
glibc-static-2.39-2.fc40.x86_64 : C library static libraries for -static linking.
Repo        : @System
Matched from:
Other       : *libc.a

$ dnf repoquery -l glibc-static | grep libc.a
/usr/lib/libc.a
/usr/lib64/libc.a

So until this issue is fixed, it'll vary based on build host:

# Split to multi-line for readability:
$ zig cc -static -target x86_64-linux-gnu -o hello \
  hello.c \
  /usr/lib64/libc.a \
  /usr/lib/gcc/x86_64-redhat-linux/14/libgcc_eh.a

$ ldd hello
        statically linked

# Despite that, seems to still be dynamically linked?
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, with debug_info, not stripped

$ nm -an hello | grep dl_open
0000000000290e60 t dl_open_worker
0000000000291190 t _dl_open
00000000002914c0 t dl_open_worker_begin

Perhaps it needs something else for file to not treated it as dynamically linked?

• I assume that's due to the _dl_open. I'm aware that glibc can be statically linked and still have _dl_open, so it may be due to that.
• I'm more familiar with Rust where the equivalent glibc static link build does not have the extra dynamic output from file / nm commands.
• EDIT: I probably should have run it first, the above approach segfaults 😂 (despite being run on the same build host) so I'm definitely missing something else, or doing something wrong?

Related issues:

• unable to find Static system library 'gcc_eh' #17268 (comment)
• cargo zigbuild doesn't support static glibc builds with an explicit --target rust-cross/cargo-zigbuild#231 (comment)