HN Reader

We tried this a few years back with a very loaded Go server using SQLite (actual C SQLite, not modernc.org/sqlite) and something made performance tank... likely some difference between glibc and musl. We never had time to hunt it down. We talked to Zig folk about sponsoring them to work on it, making performance comparable to glibc-built-SQLite, but they were busy at the time.

This post seems to be missing an additional opportunity: Zig's build can involve go build! Use Build.addSystemCommand, have it depend on library step, and have the install step depend on that step. This reduces the steps to build to just 'zig build'

All the magic seems to happen in

    const lib = b.addLibrary(.{
        .linkage = .static,
        .name = "cgo_static_linking",
        .root_module = lib_mod,
    });

and

/* #cgo LDFLAGS: -L./zig-out/lib -lcgo_static_linking -static #include "zig_lib.h" */

Now I can only guess why it works. A bit of an explanation wouldn't hurt. Good post btw

Hi HN, I tried doing this 2 days ago for AWS lambda arm64 runners. And it did not work. Has anyone successfully built a statically linked golang binary arm64 runners in Lambda?

Thanks in advance.

what is the upside for this rather than just building cgo with musl? what does zig add?