If I'm not mistaken shared libraries are also shared (for the ro sections) in RAM. Saving 10MB on disk is mostly negligible nowadays but 10MB in RAM less so, and 10MB in cache is very much significant.

I really think that the linked post throws the baby out with the bath water, library versioning issues can be handled by the package manager to become effectively non-issue. DLL hell is a thing on Windows because it lacks a proper package manager. On a case-by-case basis applications that can't be packaged properly (proprietary binaries for instance) can be statically linked.

In my experience that's how it works on Linux and for the BSDs and as far as I'm concerned it hasn't caused many issues. Maybe I've just been lucky.

Shared libraries are shared in RAM between processes. But I believe the cache for each process is not shared. If three processes currently have the same shared lib code (or any shared memory) in their working set, they will each work it into cache independently. This sounds inefficient but is rare in practice and maintains process isolation. The added complexity of cache sharing would not be worth it.

If I have this wrong, someone please correct me.

That is wrong for caches that are based on physical addresses.

KCalc with the KDE libs, Qt, X, libc, and all of their dependencies would become far bigger than 10 MB.

Kcalc doesn’t use the whole qt library, the whole X library, the whole kDE library, or the whole C library. When you statically link, only the functions that are actually called are included. This can trim a lot of space.

> When you statically link, only the functions that are actually called are included.

This is not true in general.

For this code:

    #include <stdio.h>

    int main(void)
    {
      puts("hello world\n");
      return 0;
    }

both GCC 7.3.0 and Clang 6.0.0[1] on my system generate an 828 KB binary when compiling with -static. The binary includes a whole bunch of stuff, including all the printf variants, many of the standard string functions, wide string functions, lots of vectorized memcpy variants, and a bunch of dlsym-related functions.

By using -ffunction-sections -fdata-sections -Wl,--gc-sections (per https://news.ycombinator.com/item?id=19170667) I get this down to 804 KB. Still not quite what you suggest.

[1] Clang might just be using the same linker as GCC here, and you might blame including the extra stuff on the linker.

    $ musl-gcc test.c -O2
    $ ls -laB a.out
    .rwxr-xr-x 15,776 roblabla 15 Feb 16:49 a.out
    $ musl-gcc test.c -O2 -ffunction-sections -fdata-sections -Wl,--gc-sections -static
    $ ls -laB a.out
    .rwxr-xr-x 17,864 roblabla 15 Feb 16:48 a.out

Static linking with MUSL added 2088 bytes of overhead. Likely only the code that was needed.

It's true that without proper care, you might end up importing a whole lot of useless stuff though.

That's great, but can you now demonstrate the same with Qt and KDE, as you claimed above?

FWIW, I believe (but could very well be wrong) the reason that this works this well with MUSL is that every function is defined in its own translation unit. I doubt that Qt and KDE do that.

The library/project has to be designed right. Musl has dummy references that make static linking work without pulling in a bunch of junk. This is very much a language/project issue and I wish more languages actually looked at the huge mess of dep graphs that are needed for simple programs.

I think you will have better luck static linking against a different libc, like uClibc or musl libc. Statically linking against glibc doesn't work very well, and isn't supported by upstream.

uClibc and musl libc have much better support for static linking, and you will be able to make a much smaller binary with them than you would static linking against glibc.

You want -flto and to strip the binary of symbols if you are looking for a small executable size. The C runtime is about 800K.

-flto combined with -static doesn't seem to do anything for me:

    $ gcc -O3 foo.c -flto -static -o foo
    $ du -sh foo
    828K foo
    $ strip foo
    $ du -sh foo
    760K foo

Could you post a complete command line and the version of the compiler you have showing how to make this work with static linking?

In my experience compilers are very bad at figuring out what is "actually called", probably because this is non-trivial in C and C++.

It's not that complicated. -ffunction-sections -fdata-sections arguments to gcc coupled with --gc-sections argument to the linker will get rid of most of the fat.