Because of that, in many Linux distributions there are few, if any, static executables. Due to this, it may happen that a botched glibc upgrade makes the system unusable, because no executable can be started to repair it (nowadays many distributions have a static busybox for such situations). I have seen this a couple of times, and the first time I could not understand what happened, because I was used to older systems, where the commands that I tried to execute (e.g. ls or mv) had been statically linked. Such a thing could never happen in a traditional UNIX or Linux system, before glibc disallowed static linking.
The GNU libc should have been split into a libc with most of the functions, which may be linked statically without problems, and into a small library with the name resolving functions, which could be linked dynamically only by the programs which need those functions.
Even better, the name resolving functions should have been organized in such a way to be able to use their default configuration with static linking and choose dynamic linking only when you really intend to override the default configuration when using less common services, e.g. NIS.
It should be easy enough to repair but it was just an old laptop I wanted to test something on so I ended up throwing the laptop back in the draw instead.