Arch Linux

--enable-static-nss isn't default option and after brief search I couldn't find a distro that enables it (I looked at fedora,debian and gentoo) therefore I'm not sure if enabling it wouldn't lead Arch into some obscurity. Do you know of any downsides of enabling that option?

https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F

Quote:

Internally glibc continues to use dlopen for several major subsystems including NSS, gconv, IDN, and thread cancellation. For example NSS (for details just type info libc "Name Service Switch") won't work properly without shared libraries. NSS allows using different services (e.g. NIS, files, db, hesiod) by just changing one configuration file (/etc/nsswitch.conf) without relinking any programs. The disadvantage is that now static programs or libraries need to access shared libraries to load the NSS plugins to resolve the identity management (IdM) query. A solution to this problem for statically linked application has been proposed but not implemented and involves the potential use of /usr/bin/getent and an IPC mechanism to allow statically linked applications to call out to getent to implement the IdM APIs.

Lastly, you could configure glibc with --enable-static-nss, but this is not recommend. In this case you can create a static binary that will use only the services dns and files (change /etc/nsswitch.conf for this). You need to link explicitly against all these services. For example:

gcc -static test-netdb.c -o test-netdb \
-Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group

The problem with this approach is that you've got to link every static program that uses NSS routines with all those libraries. In fact, one cannot say anymore that a glibc compiled with this option is using NSS. There is no switch anymore. Thus using --enable-static-nss makes the behaviour of the programs on the system inconsistent.

Thx, that validate my concern about risks of enabling that option. I think this should be closed as wontfix then.

Perhaps building your static programs using community/musl and CC='musl-gcc -static' is a viable option? Due to the inability of core/glibc to statically link in truth, I build both community/busybox and aur/pacman-static using musl for fully independent recovery binaries.

@eschwartz, For my requirement, I have to compile tmux as static, tmux uses getgrnam_r() somewhere down the line which requires NSS. the static tmux which I compiled worked fine in arch based containers, but broke when I tried to run it in ubuntu based container. So, I recompiled glibc with --enable-static-nss to generate glibc.a with nss functions included, then generated static tmux. The newly generated static tmux worked fine in ubuntu.

I'm not sure what are the consequences we will face if we add this flags, but it helped to fix the issue. I also agree that this flags doesn't make sense because glibc going to use dlpoen() anyway for a different nsswitch.conf or for some other reason.

The reason I raised this bug is, this flags is going to affect only libc.a, it fixes one scenario to make the glibc using static binary nearest to the true static binary. if anyone going to use libc.a, then that person has to use this flag anyway (otherwise that person will face the same issue which I faced), so why not add that flag by default?

getgrnam_r does not require NSS, that's the entire point of switching to musl. getgrnam_r merely requires... the function getgrnam_r, which might be implemented on glibc using the NSS facilities with accompanying dlopen(), but not necessarily on other libc implementations...

Specifically w.r.t. musl, which "obviously musl does not have (or want) NSS." you will simply end up with a getgrnam_r function that only returns info from /etc/group and friends, but does not use LDAP etc. to do lookups. It does support nscd: https://wiki.musl-libc.org/open-issues.html#NIS/LDAP/other-user-databases

Given the specific problem domain here, this might often be an entirely acceptable sacrifice. musl's failure to support NSS is like to bite people in two somewhat avoidable ways:
- non-DNS lookup of hostnames (e.g. mDNS, localhost not hardcoded in /etc/hosts), could be implemented via a local caching server to handle this as it's now a DNS lookup
- uid/gid lookups only check /etc/{passwd,group}, not ldap, but using ldap is a pretty big sysadmin decision that you don't just not notice... most people do not do this... you could run nscd even so