compiler_rt missing `__gnu_thumb1_case_shi`

[haydenridd]

Zig Version

0.14.1

Steps to Reproduce and Observed Behavior

You have application code:

main.c

int gccFunc(int val);
int main(void)
{
    int v = gccFunc(1);
    return 0;
}

And then static library code:

gcc.c -> libgcc.a

int gccFunc(int a)
{
    return a + 10;
}

The static library is compiled into libgcc.a in build.zig, and then manually linked to the executable via linkSystemLibrary():

const std = @import("std");

pub fn build(b: *std.Build) void {
    const target = b.standardTargetOptions(.{});
    const optimize = b.standardOptimizeOption(.{});

    const library_name = "gcc";
    const libgcc_mod = b.createModule(.{
        .target = target,
        .optimize = optimize,
    });
    libgcc_mod.addCSourceFiles(.{
        .files = &.{"lib/gcc.c"},
        .flags = &.{},
    });
    const libgcc_lib = b.addLibrary(.{
        .name = library_name,
        .linkage = .static,
        .root_module = libgcc_mod,
    });
    b.installArtifact(libgcc_lib);

    const exe_mod = b.createModule(.{
        .target = target,
        .optimize = optimize,
        .link_libc = true,
    });
    exe_mod.addCSourceFiles(.{
        .files = &.{"src/main.c"},
        .flags = &.{},
    });
    exe_mod.addLibraryPath(b.path("zig-out/lib"));
    exe_mod.linkSystemLibrary(library_name, .{
        .needed = true,
        .preferred_link_mode = .static,
        .use_pkg_config = .no,
    });

    const exe = b.addExecutable(.{
        .name = "system_lib_bug",
        .root_module = exe_mod,
    });

    exe.step.dependOn(&libgcc_lib.step);
    exe.verbose_link = true;

    b.installArtifact(exe);
}

This will fail with the error:

error: ld.lld: undefined symbol: gccFunc
    note: referenced by main.c:4 (src/main.c:4)
    note:               /home/hayden/Documents/zig/system-lib-bug/.zig-cache/o/a63c1390c1be2c14448d5a0f31a42c21/main.o:(main)

Examining the build-exe call you can see needed-lgcc is added correctly:

/home/hayden/.zvm/0.14.1/zig build-exe /home/hayden/Documents/zig/system-lib-bug/src/main.c -search_paths_first_static -needed-lgcc -ODebug -L /home/hayden/Documents/zig/system-lib-bug/zig-out/lib -Mroot -lc --verbose-link --cache-dir /home/hayden/Documents/zig/system-lib-bug/.zig-cache --global-cache-dir /home/hayden/.cache/zig --name system_lib_bug --zig-lib-dir /home/hayden/.zvm/0.14.1/lib/ --listen=- 

However looking at the linker call, libgcc.a is missing!

ld.lld --error-limit=0 -mllvm -float-abi=hard --entry _start -z stack-size=16777216 --build-id=none --image-base=16777216 --eh-frame-hdr -znow -m elf_x86_64 -o /home/hayden/Documents/zig/system-lib-bug/.zig-cache/o/88b05d7ddc13501e1f580717076f3b01/system_lib_bug /usr/lib/gcc/x86_64-redhat-linux/14/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/14/../../../../lib64/crti.o -rpath /home/hayden/Documents/zig/system-lib-bug/zig-out/lib -L /usr/lib/gcc/x86_64-redhat-linux/14/../../../../lib64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /home/hayden/Documents/zig/system-lib-bug/.zig-cache/o/a63c1390c1be2c14448d5a0f31a42c21/main.o /home/hayden/.cache/zig/o/ee9c7c2323795433f5cfe8074ac46f67/libubsan_rt.a --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/hayden/.cache/zig/o/198003ee6be6fa4a77cf81686a4c740a/libcompiler_rt.a /usr/lib/gcc/x86_64-redhat-linux/14/../../../../lib64/crtn.o

This seems to be directly related to the name "gcc", when changing the name in build.zig all works as expected:

const library_name = "not_gcc";

Perhaps there is some conflict given this is a standard name for a C standard library file?

Expected Behavior

libgcc.a should be valid to add to an executable using linkSystemLibrary().

[andrewrk]

Working as designed. Can you please elaborate on why you expect different behavior by explaining your use case?

[haydenridd]

Working as designed. Can you please elaborate on why you expect different behavior by explaining your use case?

For sure, am I missing something obvious for why my libgcc.a file doesn't get added as a linker arg? But the exact same library with any other name, for instance libsomethingelse.a gets added?

[alexrp]

Just to elaborate on why it's as designed, it's because libgcc is (in slightly simplified terms) another name for libcompiler_rt, which causes the compiler to give it special treatment:

zig/src/target.zig

Lines 298 to 318 in bc8e1a7

	pub fn classifyCompilerRtLibName(name: []const u8) CompilerRtClassification {
	if (std.mem.eql(u8, name, "gcc_s")) {
	// libgcc_s includes exception handling functions, so if linking this library
	// is requested, zig needs to instead link libunwind. Otherwise we end up with
	// the linker unable to find `_Unwind_RaiseException` and other related symbols.
	return .both;
	}
	if (std.mem.eql(u8, name, "compiler_rt") or
	std.mem.eql(u8, name, "gcc") or
	std.mem.eql(u8, name, "atomic") or
	std.mem.eql(u8, name, "ssp"))
	{
	return .only_compiler_rt;
	}
	if (std.mem.eql(u8, name, "unwind") or
	std.mem.eql(u8, name, "gcc_eh"))
	{
	return .only_libunwind;
	}
	return .none;
	}

Even in the absence of the Zig compiler, it is a really bad idea to name your library libgcc (or any of the above) unless you know what you're doing.

[haydenridd]

Got it! I figured this was something to do with the naming. For context I'm not naming any libraries that by choice, but rather using a pre-compiled libc for a freestanding target (the names of which are libgcc.a, libc.a, libm.a, etc). Simply renaming them to something else is a valid workaround. I've fiddled around just a little with setLibCFile() but AFAIK it doesn't quite work for odd freestanding pre-compiled libcs like I'm dealing with.

Appreciate the clarification!

[alexrp]

For context I'm not naming any libraries that by choice, but rather using a pre-compiled libc for a freestanding target (the names of which are libgcc.a, libc.a, libm.a, etc).

Without having looked, I would say there's at least a good chance that you can entirely omit its libgcc.a in favor of Zig's own compiler-rt, FWIW.

[andrewrk]

Note that in this case libgcc.a being omitted by Zig is actually working in your favor, because that library has a set of functions with standard names and ABIs, which Zig will always provide. So it's correct to be omitted! Zig is providing that functionality for you always, no matter what.

You shouldn't rename libgcc.a to something else, Zig's default behavior of ignoring it and providing compiler_rt is very likely what you want instead.

[haydenridd]

Note that in this case libgcc.a being omitted by Zig is actually working in your favor, because that library has a set of functions with standard names and ABIs, which Zig will always provide. So it's correct to be omitted! Zig is providing that functionality for you always, no matter what.

You shouldn't rename libgcc.a to something else, Zig's default behavior of ignoring it and providing compiler_rt is very likely what you want instead.

Nice, appreciate the explanation! In this extremely unfortunate case, it looks like "my" libgcc provides a symbol __gnu_thumb1_case_shi that's used by libc_nano.a (newlib nano is the flavor of std lib) that isn't provided by Zig:

error: ld.lld: undefined symbol: __gnu_thumb1_case_shi
    note: referenced by nano-vfprintf_i.c
    note:               libc_a-nano-vfprintf_i.o:(_printf_i) in archive /home/hayden/gnu_arm/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/arm-none-eabi/lib/thumb/v8-m.base/nofp/libc_nano.a

Something to do with however newlib is implementing vprintf for this particular ARM standard. I'll dig some more into what that symbol actually is/does. It probably would be cleaner to just compile newlib from source rather than keep messing around with the pre-built binaries that come with the arm-none-eabi-gcc compiler but was trying to explore the "easiest" path to get people used to developing w/ that compiler to switch to Zig's!