Hacker News Reader

Comment by drewg123 | Hacker News Reader

The fact that it produces a single static binary is one of the nicest things about golang.

This used to be easy with C (on BSD & Linux) a long time ago, but then everything started to depend on various shared libs, who then depend on other libs, then things started to even dlopen libs behind your back so they didn't even show up in ldd, etc. Sigh.

View on HN

> The fact that it produces a single static binary is one of the nicest things about golang.

Not only that it can also cross compile for different architecture and operating systems.

We used that to make a simple "VPN diagnostics" app for our helpdesk (app checked connectivity and config of the machine then displayed the summary page). Only thing that needed to be written per-os is how to call a browser to display the report

interesting. could you share what specifically the report had?

I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now.

Just do `release --name "mycoolprogram" --version "0.1.0"`

and it will output all of your labeled release binaries for every platform your code supports.

check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sports 40 different platform combos [1]

[0] - https://github.com/donuts-are-good/release.sh

[1] - https://github.com/donuts-are-good/bearclaw/releases/latest

looks a heck of a lot simpler than goreleaser! I love goreleaser but it gets outrageously complicated.

Thanks for checking it out :) I'm not going to pretend I haven't been refreshing the page waiting for bugs and comments

So I always assumed this was the case for other compiled languages. Is this something special in Golang and/or recently created languages?

I think the main thing that's different about Go compared to more old-school languages is that the Go binary distribution includes the cross-compilers right out of the box. So anybody who can run "go build" can also cross-compile their application -- and, importantly, all of its library dependencies -- for any architecture that Go supports.

On the other hand, if you want to cross-compile a C program using GCC, you need to separately build and install a complete gcc+binutils toolchain for every individual arch that you want to target. And you have to handle the dependency management yourself, which may be tricky if your dependencies' build scripts weren't designed with cross-compilation in mind.

No. Some bytecode compiled languages are compiled and require at least an archive to be unzipped or at least the virtual machine pre installed.

Java is an example -- you'll want your your system java deployment to match the stuff stashed in your jar.

Erlang is compiled but usually releases bundle the VM up with the project, so you typically deliver a full directory with the VM packed in there.

On top of this, with java, the jvm is itself dynamically linked to libc most of the time.

Golang is special because pure Go programs tend to have a closed ecosystem with its own linker (that typically don't link to libc or other C libs) so it makes static linking very easy. Other languages can certainly do static linking, but it tends to be a bit challenging to set it up on different OS's due to the need to have all needed C libs as static libs and then instruct the linker appropriately.

Not dynamically linking to libc is pretty unusual. The libc-equivalent parts are in the Go runtime, statically linked.

From what I have seen in major OSS projects like systemd and PostgreSQL, nothing seems to support static linking, to the point where some contributors get annoyed when you ask for it.

Seems like the C/C++ ecosystem will stay dynamically linked, even with a lot of the industry shifting towards statically linked, fat binaries as disk space is pretty cheap.

I wonder how much simpler Linux packaging would be if everything was statically linked...

Packaging would be simpler, but you probably have to update the whole OS and all your installed apps when a security update for a common library is released.

Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :(

The docker world is a neat example of this. The stories of ${absurdly high percent} of containers having vulnerabilities only gets to claim that because of "unpatched libraries." If you reduce it to the number of containers with exploitable vulnerabilities, it is still non-zero, but not nearly as high.

The problem is having to wait for all those applications to push updates when a vulnerability is found in a common library

That is the thing, though. For most applications, those vulnerabilities in a common library are not relevant. That is what I was talking about in saying that it is in code that isn't used by them.

You are, of course, right that it has the possibility of happening. But by and large, it doesn't happen there any more often than it does in the dynamically linked cases. And, by and large, the dynamically linked cases are often a lot more complicated to deploy. (Granted, deployment for either should be doable nowadays.)

The dream, of course, is you just patch the library and call it a day. The reality seems to usually be a circus check on every application that you have deployed to see if they are impacted anyway.

The solution to this is to make the build process as simple as possible. Then pushing updates has a much lower maintenance cost.

I can be confident I will be able to build >90% of go programs by cloning the repo and calling go build.

Simpler but small updates, like say openssl, become massive distro updates. There's a reason why everyone went with shared libs when they became stable.

A system with shared libraries also needs an update for the security fixes. There is no avoiding the update step. However, the only difference is the size of the update. If update process is robust, size of the update shouldn't matter, isn't it?

It does matter. If there is a problem with openssl, just the openssl maintainers have to push an update and everything on your system is secure.

If everything is statically linked, you need to wait for every maintainer of every single program on your system to rebuild and push an update. You're basically guaranteed that there is always _something_ missing important patches

The matter isn't the binary size of the update. It is the size of the crowd of people and parties involved in the update: For a bunch of statically linked applications, you need to involve all the application people/vendors. For a bunch of dynamically linked applications depending on a shared library, you (ideally) just need to involve the one library's people/vendor.

And "involve" might mean: wait for a bunch of unresponsive external parties to produce a new binary each for a security issue they might not care about. Of course on very different timelines, etc.

Docker images are static linking for the modern era.

Funnily enough I was looking at an issue in my one of personal projects last night about asking me to statically link libstdc++ - it's something I was interested in doing because I spent way too long spinning my wheels on an issue caused by loading an outdated libstdc++.so.6, but I read that statically linking can cause issues if your code loads another library that dynamically links libstdc++... which I'm pretty sure my project does (it's a pass-through between an executable and another library). So I want to, but it sounds like if I do it might work but be fragile at best.

IME, using musl, compiling static binaries written in C is as easy as it was before glibc changes and as it has always has been on NetBSD. I compile static binaries written in C every day on Linux. I never encountered any problems compiling static binaries on BSD.

That’s great if your only dependency is libc. It gets progressively harder the more dependencies you need, and it becomes downright untenable the moment you run into some dependency with a dlopen-based plugin architecture.

Can you link something substantial, like Firefox, statically on NetBSD?

Compiling Firefox on NetBSD (dynamically) takes longer than compiling the kernel, maybe even longer than compiling an entire base system. It's been a long time since I tried it but it just took far too long so I lost interest. Granted, the computers I use have limited resources. Anyway, I gave up on graphical browsers many years ago. It seems I prefer "unsubstantial" programs.

Graphical web browsers from "tech" companies (and their partners, like Mozilla) are too large, too complex, too difficult for the user to control. IMHO.

Many of the static binaries I use rely on dependencies other than libc. Most are small programs. Out of personal preference, I generally try to avoid large programs with numerous dependencies. Exception might be something like ffmpeg. Static binary for the author is 21M but package from repository is 84M so the static binary uses less space. ffmpeg has many dependencies besides libc.

very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great.

I run a few Go apps, all are single executables, upgrading to new releases has never been easier.

if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

> CGO_ENABLED=1 CC=musl-gcc go build --ldflags '-linkmode external -extldflags=-static'

Unless you cant use musl for some reason, but that’s a glibc problem, not Go

Some people are writing alternative via WebAssembly.

For instance wazero which I'm really excited about.

https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm...

In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace) because it is independent of dlopen.

And there's also "purego" as an implementation that directly generates shellcode.

Maybe those will help you, too?

I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.

[1] https://github.com/Binject/debug

[2] https://github.com/ebitengine/purego

very useful,thanks

This is generally only true with CGO_ENABLED=0.

I've found many times that a go binary, even if it has no cgo or cgo dependencies, will randomly require glibc on the target system to execute if you don't explicitly disable cgo in your build.

You can still do that with musl, can’t you? Can make a static c binary with that

Reply on news.ycombinator.com