> all kinds of features in the libc (locale (through iconv), NSS, IDN, ...) require dynamic linking (...)
These are all features which have been shoehorned into libc on Linux, but only work when it's a shared library because they rely on shared state. I would argue a cleaner way of implementing them would have been as services, but alas, you have what you have.
Those features use dynamic linking so that they can load only the necessary implementations at runtime - eg if you aren't using LDAP name lookups, then the NSS won't load the library that does LDAP name lookups.
But of course you could still easily mmap() a file to achieve the same thing (even from the shared library .init functions).
I can understand that the shared section might be abused by goofy programmers ("Hey guys! We don't need to open a file for storage, we can just build it into the DDL!") ... but is there a reason you think it's a bad idea otherwise?
The above sentence could be misconstrued.
I assume when you say static libraries, you mean standard shared libraries (i.e. those listed when you run ldd). Not statically-linked libraries?
If you want to share state between processes, the library must explicitly set up a shared mapping - but of course a statically linked library can do this just as well.
A statically-linked library won't share any state with other users of the library. It's statically-linked into the binary. State will be shared only with the instances of the same binary.