[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Static binaries and nss (dlopen actually)

From: Samuel Thibault
Subject: Static binaries and nss (dlopen actually)
Date: Wed, 18 Feb 2015 02:26:33 +0100
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]