[arp242]

You can statically link libc in Rust too; at least, if teh interwebz is correct (not a Rust expert); you just need some extra flags.

This is actually not that different from Go in practice; many Go binaries are linked to libc: it happens as soon as you or a dependency imports the very commonly used "net" package unless you specifically set CGO_ENABLED=0, -tags=netgo, or use -extldflags=-static.

[Conscat]

Statically linking libC is problematic in various ways. I really appreciate that Zig has its own runtime that is designed specifically for this use case.

[Kamq]

> Statically linking libC is problematic in various ways.

Are we just talking about standard rop gadget vulnerabilities, or is there something else that's a problem with it?

[thristian]

glibc, Linux's traditional libc, can dynamically load hostname resolution policies, but that only works if the executable has access to dynamic loading, i.e. if it's not a static executable.

Dynamically loading hostname resolution policies doesn't happen often, but when it does happen it's a right pain to diagnose why some tools see the right hostname and other tools don't.

[maeln]

You can, but usually, if you really want a binary with no runtime dependencies, most people will just compile their code against musl libc instead.

The only issue is that some lib sometime do not compile (or at least without some workaround) with musl. Although it often concern one specific platform (looking at you Mac OS).