Static linking would never cross process boundaries, would optimize for modules that are actually called from the program that the libraries are being linked to and has absolutely nothing to do with IPC.
Dynamic linking is useful, but not always necessary and not always appropriate and does not result in 'calculator apps that are hundreds of megabytes', it might be 10Mb or so, which is still large but not comparable.
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.
If I have this wrong, someone please correct me.
This is not true in general.
For this code:
#include <stdio.h>
int main(void)
{
puts("hello world\n");
return 0;
}
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.
$ gcc -O3 foo.c -flto -static -o foo
$ du -sh foo
828K foo
$ strip foo
$ du -sh foo
760K foo
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.
$ 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
It's true that without proper care, you might end up importing a whole lot of useless stuff though.
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.