Hello, Static binaries currently can't make use of nss functions (or more generally really use dlopen-ed libraries). What happens is that when the nss plugin library gets loaded, e.g. /lib/i386-gnu/libnss_files.so.2, by dependency libc.so gets loaded, i.e. a *second* libc (the first being the one statically linked into the binary). When the nss plugin tries to e.g. open /etc/passwd, it calls open() from that second libc, which ends up calling _hurd_ports_use(), which returns EGRATUITOUS because _hurd_ports is NULL: indeed the second libc has not called _hurd_init to initialize itself.
So basically the concern is that the second libc hasn't initialized its structures. Should we really do it? It'd notably mean a second set of file descriptors, and thus plugin functions must not return file descriptors since they'll not be in the same space as the statically-linked application... Should we then rather manage that the loaded libc.so accesses the statically-linked _hurd_ports etc? This issue notably makes the busybox build abort. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150218012633.gq2...@type.youpi.perso.aquilenet.fr
