Yawning Angel:
Having to rebuild the browser when the libc needs to be updated seems terrible as well.
Why is it terrible? Using static linking drastically reduces overall *complexity* (~1/security). If you do use libc code in your stuff then it's a part of this stuff. If there is a bug in libc - just rebuild your broken software. It either works or not. Doing dynamic linking is leaving it in superposition state.
I consider having the browser that builds for >30m is way more terrible.
From https://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/... :
I prefer static linking:
Executing statically linked executables is much faster, because there are no expensive shared object lookups during exec().
Statically linked executables are portable, long lasting and fail safe to ABI changes -- they will run on the same architecture even in 10 years time. Never expect errors like /lib/ssa/libstdc++.so.6:version 'GLIBCXX_3.4.4' not found again.
Statically linked executables use less disk space. Most executables use only a small subset of the functions provided by a static library -- so there is absolutely no reason to link complete static libraries into a static executable (e.g. spoken for a hello_world.c you only need to link vprintf statically into the executable, not the whole static libc!). The contrary is true for dynamic libraries -- you always use the whole library, regardless what functions you are using.
Statically linked executables consume less memory because their binary size is smaller and they only map the functions they depend on into memory (contrary to dynamic libs).
The reason why dynamic linking has been invented was not to decrease the general executable sizes or to save memory consumption, or to speed up the exec() -- but to allow changing code during runtime -- and that's the real purpose of dynamic linking, we shouldn't forget that.
-- Ivan Markin