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.
