This partially fixes static-only NSS support (bug 27959): The dns
module no longer needs dlopen. Support for disabling dlopen altogher
remains to be added.
This commit introduces module_load_builtin into nss/nss_module.c, which
handles the common parts of loading the built-in nss_files and nss_dns
modules.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
This partially fixes static-only NSS support (bug 27959): The files
module no longer needs dlopen. Support for the dns module remains
to be added, and also support for disabling dlopen altogether.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
https://sourceware.org/bugzilla/show_bug.cgi?id=27077
Before reloading nsswitch.conf, verify that the root directory
hasn't changed - if it has, it's likely that we've entered a
container and should not trust the nsswitch inside the container
nor load any shared objects therein.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
I used these shell commands:
../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")
and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 6694 files FOO.
I then removed trailing white space from benchtests/bench-pthread-locks.c
and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this
diagnostic from Savannah:
remote: *** pre-commit check failed ...
remote: *** error: lines with trailing whitespace found
remote: error: hook declined to update refs/heads/master
This provides the struct nss_module type, which combines the old
struct service_library type with the known_function tree, by
statically allocating space for all function pointers.
struct nss_module is fairly large (536 bytes), but it will be
shared across NSS databases. The old known_function handling
had non-some per-function overhead (at least 32 bytes per looked-up
function, but more for long function anmes), so overall, this is not
too bad. Resolving all functions at load time simplifies locking,
and the repeated lookups should be fast because the caches are hot
at this point.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
