[roland at redhat.com: Re: More info on static binary/libnss* mystery]

Gerard Beekmans gerard at linuxfromscratch.org
Mon Oct 7 10:02:27 PDT 2002

On October 7, 2002 09:42 am, Bruce Dubbs wrote:
> problem a little better.

When you create a statically linked program, it's not 100% statically linked. 
There's still a library part of Glibc called the NSS library (Name Server 
Switch). They are rarely available as static libraries but don't show up when 
running "ldd". These libraries are called by Glibc itself.

So a static library might need functions from the NSS library. The NSS library 
tells apps where the passwd database is (/etc/passwd), where to look for DNS 
servers (/etc/resolv.conf), NIS(+) stuff and more of that. So an example in 
our case is Bash - it needs to (or tries to) resolve usernames, and group 
names. This needs the NSS library. Now, when we enter chroot, the Glibc 
inside /static/bin/bash will try to load an NSS library to figure out how to 
resolve a userid to a name. Without Glibc installed, there are no NSS 
libraries in /lib so it says "I have no name!"

When you do install Glibc, there are libnss* files in /lib, the static 
/static/bin/bash all of the sudden has an NSS library it can load. But...this 
NSS library is incompatible with the Glibc version that Bash was built 
against. So it finds an NSS library, and seg. faults.

One of the fixes was to sed bash and replace all NSS library names with 
something invalid like FOOBAR. This way Bash will never find /lib/libnss* 
files until you recompile Bash dynamically. We'd have to do the same with 
"ls" and other apps that might need it.

Is it clearer now?

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list