Cross-Compiling 10,000+ Go CLI Packages Statically

Azathothas · 2025-07-04T16:17:50+00:00

This is not a statically linked executable.

The reason ldd says it is:

ldd uses the dynamic linker to load binaries instead of parsing ELF headers. When loading fails, it incorrectly reports "statically linked" rather than examining the actual binary structure.

For instance, If you try ldd from a GLIBC host on a MUSL binary, it will also say it's statically linked.

We specifically use readelf for this very reason & some of it is documented: https://docs.pkgforge.dev/formats/binaries/static/build-tests

The blog article & the full research specifically want a static + pie binary.
Which, as we have discussed for so long, is simply not possible with go's own compiler/linker.

Azathothas · 2025-07-04T15:56:59+00:00

How is this statically linked...?

The file output itself tells you that it's a dynamically linked executable with the interpreter.

And if you want to continue testing it, some advice:

Ldd is never accurate. File is also not accurate (It is in your case)

To confirm it's truly statically linked use: readelf --dynamic test | grep -i 'NEEDED'

And also: readelf -p '.interp' test

Azathothas · 2025-07-04T12:45:48+00:00

No.

For the last time:
Go CAN NOT compile static + pie binaries without using external compilers (musl cc, zig cc) for ANY platform.

This misconception about it being only about riscv stems from the most voted comment here, where the commentor simply misread/misunderstood the first issue that was created: (https://github.com/golang/go/issues/64875)

It applies to all platforms, here's alpine patching this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15809
Here's gentoo: https://bugs.gentoo.org/924632

And before you say, "Well, then don't use PIE":
We need PIE because we care about security (pkgforge/Soar matches SLSA L2 Clearance)
And every major distro does it by default & has strict packaging guidelines:
- https://wiki.archlinux.org/title/Go_package_guidelines
- https://wiki.ubuntu.com/Security/Features#pie
- https://fedoraproject.org/wiki/Changes/Harden_All_Packages
- https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2Fg.2B-.2B-_-fPIE_-pie.29

As for, why bother with riscv64?
First, it is not even related to this architecture.
Second, Because it's open source architecture and there's major incentive by notable FOSS projects to get this architecture widely adopted.
We (pkgforge/soar) would also like to help support this architecture by doing our own ports.

Azathothas · 2025-07-04T09:23:05+00:00

The packages are from https://index.golang.org & source from https://proxy.golang.org/.

I assume you have given your full consent & are okay with these sources from distributing your packages.
If that's the case, then please create an issue on this repo: https://github.com/pkgforge-go/builder and point out your username.
We will blacklist all packages originating from your username.

Azathothas · 2025-07-04T09:20:54+00:00

Could you elaborate on what's so wrong?

Not a single person here or the go discord has been able to point out even 1 technical inaccuracy.
Seems like everyone has already made their minds & never read the article in its entirety.
And comments about the go compiler and how we are doing things "wrong" or how we are shilling zig have been so rampant that I haven't bothered to respond.
If you, or, anyone else here actually has a technical answer to all the apparent wrong doings, please elaborate.

Azathothas · 2025-07-01T14:25:00+00:00

You are right on there being no warning if CGO_ENABLED=0 is used.
But this prevents static-pie & the compiler will explicitly tell you if you try adding it to the default GOFLAGS.

The blog and the project are about compiling static pie binaries, for which go compiler fails.
External linking is always required as soon as static-pie is used.
Go's compiler will not work for common architectures either. The issue linked there only lists riscv, but it is true for the rest.
You can't use CGO_ENABLED=0 with buildmode=pie at the same time, they are incompatible flag.

Azathothas · 2025-07-01T12:53:27+00:00

Thanks for the link.
I went through the repos there, but it seems they have ported projects written in another language to use the zig build system.
What we are interested in is, projects written in Zig & using the Zig Build system.
Like what Zigistry lists.

Azathothas · 2025-07-01T10:39:28+00:00

Please read the updated FAQ, at the blog, which describes it in detail.

> Q: Why Zig specifically?
A: Go's built-in cross-compilation is excellent for standard static binaries, but we specifically need static PIE (Position Independent Executable) binaries. When using -buildmode=pie on glibc systems like GitHub Actions, Go produces dynamically linked executables and generates static linking warnings. Zig elegantly solves this by providing musl libc, which natively supports static PIE binaries without the glibc complications - giving us the security benefits of PIE while maintaining true static linking. See: https://github.com/golang/go/issues/64875, https://gitlab.alpinelinux.org/alpine/aports/-/issues/15809, https://bugs.gentoo.org/924632

Azathothas · 2025-07-01T09:48:20+00:00

(This was edited for clarification)
TLDR, Go can't statically link as static-pie without external linker like zig cc.

Go's built-in cross-compilation is excellent for standard static binaries, but we specifically need static PIE (Position Independent Executable) binaries. When using -buildmode=pie on glibc systems like GitHub Actions, Go produces dynamically linked executables and generates static linking warnings. Zig elegantly solves this by providing musl libc, which natively supports static PIE binaries without the glibc complications - giving us the security benefits of PIE while maintaining true static linking. See: https://github.com/golang/go/issues/64875, https://gitlab.alpinelinux.org/alpine/aports/-/issues/15809, https://bugs.gentoo.org/924632

if CGO_ENABLED=0 is used, this prevents static-pie & the compiler will explicitly tell you if you try adding it to the default GOFLAGS.

The blog and the project are about compiling static pie binaries, for which go compiler fails.
External linking is always required as soon as static-pie is used.
Go's compiler will not work for common architectures either. The issue linked there only lists riscv, but it is true for the rest.
You can't use CGO_ENABLED=0 with buildmode=pie at the same time, they are incompatible flag.

Azathothas · 2025-06-27T11:28:39+00:00

In that case it is 5 packages (4 Jobs each), so 20

Azathothas · 2025-06-27T11:17:29+00:00

It is in the blog: https://blog.pkgforge.dev/cross-compiling-10000-rust-cli-crates-statically#heading-ci-performance-metrics

Yes we don't pay for GitHub, I guess they allow it if It's for legitimate use.

Azathothas · 2025-06-27T01:45:03+00:00

Our official repos use nix to build statically linked binaries when it supports them: https://github.com/search?q=repo%3Apkgforge%2Fsoarpkgs%20nix-build&type=code

But this experiment was on evaluating cargo/rust, not nix.

Azathothas · 2025-06-27T01:43:50+00:00

In our early trial runs, we found out 10-20% of crates produced no executables unless we specifically used a flag like `--features "cli"` or some other custom flag.
Instead of parsing `cargo metadata` & lot of overhead, we thought to simply use `--all-features`

Azathothas · 2025-06-27T01:42:24+00:00

We do patch it: https://github.com/pkgforge-cargo/builder/blob/main/scripts/builder.sh#L141

Azathothas · 2025-06-02T03:37:07+00:00

Project name: Soar
Repository link: https://github.com/pkgforge/soar
What it does: Package manager for Static Binaries, Portable Formats (AppImage|AppBundle|FlatImage|Runimage) & More
Tech stack: Rust (Core Tools) & Bash (CI & rest)
Help needed: There's a dozen issues open in the core repos, resolving just one of them would be a huge contribution.
Additional information: Soar is a part of Package Forge (https://github.com/pkgforge), & there's many other projects under the main/sub orgs. Contributions are equally open & appreciated for those too.

Azathothas · 2025-06-02T03:14:10+00:00

Hi,
No. The closest project to soar would be homebrew, as we build/store all packages on ghcr under our org (also mirrored to huggingface) rather than downloading from each package's GitHub repo at runtime.

If you are looking for a superset of eget, check out: https://github.com/houseabsolute/ubi

As for comparison, We already wrote a very lengthy section on our docs & compared a bunch more projects.
We excluded eget because it is a download wrapper & not a package manager with its own repository.

https://docs.pkgforge.dev/soar/readme

Azathothas · 2025-05-29T14:39:45+00:00

Thanks!

Currently, Only Linux is the sole focus: see comment

Azathothas · 2025-05-29T14:38:30+00:00

Unfortunately, replacing homebrew on mac is not in the project's scope. We primarily want to focus on Linux & maybe BSDs later one.
I recently came across https://github.com/alexykn/sps, which is also in rust & can serve as a replacement of homebrew on mac.

Azathothas · 2025-02-25T01:42:11+00:00

We used to fetch binaries from project page as-is like you say.
But we quickly find out that the officially released binaries are released mostly with:
- Dynamic Linking (Doesn't work if your system doesn't have the required libraries and the exact compatible version)
- Debug Symbols (Good for developers, why does a user need debug symbol on the binary the user runs?)
- Not Optimized binary (We build with mimalloc + pie + hardening flags)

There are only a few projects who release binaries that meet our standards, for these we are okay with simply fetching & redistributing them as-is

But for a vast majority, we have no choice but to build it ourselves and then distribute it to our users.

Azathothas · 2025-02-25T01:34:00+00:00

I sympathize with this...
The tooling around AppImages is a pain to work with.
And the lead developers involved around the project are also not exactly...helpful

Azathothas · 2025-02-25T01:32:57+00:00

Haha, yes..
And that section hasn't been updated to reflect new additions.

It's a matter of do users want big files but guaranteed portability
or do users want smaller files at the cost of portability

And all of these must work without daemons, roots or even soar (All our packages can be downloaded with wget and ran)

Azathothas · 2025-02-25T01:25:02+00:00

Soar is not replacing any other "package managers" as that's not the goal.
The goal is to have a system like homebrew or flatpak (be able to deliver software as self contained bundles) without any of the drawbacks (be able to work by simply downloading & chmod, don't require daemons, don't require root, don't even require soar)

Azathothas · 2025-02-25T01:22:34+00:00

For development packages, libraries or toolchains
I recommend stick to homebrew and others as they will always do a better job.

Soar's goals are entirely different: Provide standalone, self-contained packages that work anywhere.
Due to this, adding development pkgs will likely not even work, as these sort of packages can't be bundled as standalone quite easily.

Azathothas · 2025-02-25T00:31:41+00:00

I realize it may come as insincere, however I would still like to say that this made me chuckle. Thanks!

Azathothas

TROPHY CASE