Incidentally, cross-compiling static binaries is a hugely productive feature of Go.
> 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.
But if you're trying to produce commercial shippable software (what used to be called shrinkwrap), you're not going to fit in as easily with a package management system. Your binaries will probably need updating when the shared libraries update; that's a major headache. And this is one of the reasons why there hasn't been much of a commercial market in software for Linux. Everything generally works much more smoothly if your only dependencies are glibc and a handful of other bits.
On the other hand that is also a bit silly; if the box is owned then all else is peanuts;
I was actually surprised that the VDSO [1] page was missing from that. For those unfamiliar... the Linux kernel selects the best system call implementation for the current system and exports a special page to user-space. It also provides a few specific additional routines (generally related to getting the current time without having to jump in and out of the kernel).
I'm not advocating for this approach, but it's there and can have a big impact. As a fun exercise, I just checked how much impact this has on my VM right now...
timetest.c:
#include <stdio.h>
#include <time.h>
int main(void) {
for (int i = 0; i < 1000000000; i++) {
time(NULL);
}
}
real 0m3.589s
user 0m3.588s
sys 0m0.000s
real 0m41.436s
user 0m16.900s
sys 0m24.456s