[bobsomers]

Most static binaries are not completely statically linked. The system libstdc++ and libc as well as a few other things are almost always linked dynamically.

In particular, it’s almost impossible to get glibc to link statically. You need to switch to musl or another libc that supports it.

[sph]

Static linking means no dependencies whatsoever, so it only needs a syscall interface in the kernel. If your binary requires libstdc++, it's not static, period.

Go creates static binaries. I was a bit bummed out to learn that Rust doesn't by default since it requires glibc (and copying a binary to an older distribution fails because glibc is too old).

[dijit]

it's pretty trivial to create static binaries in Rust, but things like openssl won't compile since openssl depends on glibc.

Two commands to get you running:

1) rustup target add x86_64-unknown-linux-musl

2) cargo build --target=x86_64-unknown-linux-musl

[sph]

Yes and no, it's trivial unless you use some of the most common libraries that depend on, i.e. OpenSSL, like pretty much anything that talks with the outside world. Then it's painful. (You mentioned OpenSSL in your comment but somehow I missed that part when I replied. My bad.)

One thing Go has going for it is that they have a more complete standard library so you can do without the pain of cross-compiling—which is what you're doing if most of your libs assume you're in a glibc environment but you really want musl.

I know because I recently tried compiling a Rust application that had to run on an air-gapped older Debian machine with an old glibc, and the easiest solution was to set up a debian container, download Rust and compile there, instead of fixing all the cargo deps that didn't like to be built with musl.

[capableweb]

I just went through this recently (built a rust binary on my local machine, sent a binary to another person, they reported GLIBC errors, had to rebuild with the musl target, various crates depending on openssl failed) and found that every library that depended on openssl by default also had a `rusttls` feature in the crate that disabled openssl and enabled rusttls (https://github.com/rustls/rustls) instead.

So I just migrated everything over to that (which consisted of enabling the `rusttls` feature for every crate) and made another build with musl. Everything worked perfectly fine, and since it's not a performance sensitive application, there was basically no drawbacks. The binary became a bit bigger, but still under 4MB (with other assets baked into it) so wasn't a big issue.

[staticassertion]

Other than libc I'm not sure what else would "almost always" be linked. It's going to depend on the language, but for Go/Rust at least static linking is pretty much the default, and lots of people even link to musl.

For other languages I'd say openssl is probably the next most common.

[capableweb]

> but for Go/Rust at least static linking is pretty much the default

I don't think that's true for Rust. It defaults to depending on glibc, at least on Linux, and you need to explicitly build with musl to get static binaries.

[staticassertion]

> , and lots of people even link to musl.

[capableweb]

Not sure how much clearer I could have been about that I'm responding to the "pretty much the default" part

[manwe150]

Platform ABI typically specifies that libatomic must be dynamically linked, since otherwise libdl will misbehave. Lots of other common libraries including libpthreads, libm, libgfortran, libquadmath also are frequently linked (though commonly now are linked into libc.so for better system performance)

[sph]

Those are all glibc or GCC libraries.

There is no platform ABI mandate nor Linux kernel requirement for userspace applications to be dynamically linked to anything. If you can talk to the kernel, you can do anything those libraries can do.

[manwe150]

The linux kernel forces your application to include the vDSO shared library (by pre-loading it). You can ignore it and talk to the kernel directly, but you cannot get the same performance as you could when using that shared library.

On some architectures, atomics are implemented in the kernel by the vDSO shared library (__kernel_cmpxchg), which is supplied to user via libatomic. You can ignore it, but then you cannot interoperate other code (any which uses libatomic.so) without introducing data-races into the code which were not present in the shared-library version, since they may attempt to execute their atomics differently and thus incorrectly.

[staticassertion]

Never even heard of libatomic, where is it specified that it's required to dynamically linked? I'm surprised to hear that.