On: The Linux Kernel Prepares for Rust 1.77 Upgrade

[Narishma]

But C doesn't statically link the standard library by default like Rust does.

[habibur → Narishma]

Hello world deps for C :

    linux-vdso.so.1 (0x00007fff25cb8000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fe5f08d9000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe5f0ae2000)

And for Rust

    linux-vdso.so.1 (0x00007ffc109f9000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8eda404000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f8eda222000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8eda4a8000)

Rather Rust has 1 more dynamically linked library than C.

[fl0ki → habibur]

That might be true for Hello World, but libgcc_s is where a lot of builtins for C itself go, so you'll find it ends up linked into a lot of non-trivial C programs as well. See https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

[Kamq → habibur]

You missed the word "statically" in the post you commented on.

Dynamically linked libs rarely contribute heavily to binary bloat

[habibur → Kamq]

The benefit of statically linking becomes moot when it doesn't reduce the number of dynamically linked libraries. That's the point.

[Dylan16807 → habibur]

That's not why rust statically links the runtime. The main benefit is that they don't have to try to design and maintain a stable ABI for it. Which is not moot.

More generally, you statically link something to avoid distribution hassles of various kinds, not because you care about the specific number.