Re: Static binaries and nss (dlopen actually)
The short answer is that it's pretty well hopeless. For the Hurd you
really really do not want to use static linking. Because of the structure
of the system, it's much like having a quarter or third of the Linux kernel
baked into each application binary.
On Linux and other Unix-like systems, we can get away with the "multiple
libcs" situation because there really is not very much information that
they need to share. We have a little bit of effort for one libc to notice
the sbrk usage of the other libc, but beyond that they can be ignorant of
each other's existence and get along OK.
In the Hurd, there is so much more crucial state of the process that is
maintained only by libc that it's a wholly different picture. If you have
two Hurd libcs, each one will have its own idea of file descriptors, of
signals and the signal state of each thread, and on and on. If we bent
over backwards to invent new ways for them to communicate with each other,
it would just wind up being some bad kludges implementing the crux of what
dynamic linking is really about. There is really no reason not to just use
actual dynamic linking instead.
Reply to: