On Fri February 3 2006 10:14, Michael S. Zick wrote: > Group, > > An update on the discussions in m-l threads: > re: http://list.linux-vserver.org/archive/vserver/msg09336.html > re: http://list.linux-vserver.org/archive/vserver/msg12349.html > - - - snip - - - > > messages - pointing to the culprits: > > <quote> > warning: Using 'getgrent' in statically linked applications requires at > runtime the shared libraries from the glibc version used for linking. > </quote> > > With the same warning for: > setgrent, endgrent, getpwent, getpwnam, getpwuid, setpwent, endpwent, > getaddrinfo, getservent, setservent, endservent > > There might be others, those are the ones that Bash-3.1 complains about. > - - - Yup, there are others - - - > > The solution is to include some 'linker magic' in the build of Bash (and > the VServer tools) to include the glibc static library implementation of > those calls. > Close, but no golden ring.
First, you have to build a special version of glibc with the dynamic, name system service disabled using instead the older static nss. (The glibc doc's claim it can be done, but I haven't tried it.) After all of that work, a static link of the VServer tools against the special glibc is still just a work-around, same as if the tools where linked against a *libc* that does not provide dynamic nss. I.E: A lot of work for no noticeable benefit or even lost functionality. When the linux dynamic loader can unlink and relink a different DSO in a process image - the situation might change. That feature has been on the glibc wish list for nearly a decade - don't hold your breath. None of this means that you can not use glibc with the dynamic nss enabled, it only places restrictions on version compatibility of the libraries in the host and the guest. Aw, well, back to my own project that sidesteps this whole issue. Mike _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
