Re: More info on static binary/libnss* mystery

[Roland McGrath <roland at redhat dot com>]

I'm afraid you are SOL if you want to use stock glibc 2.3 with those old
static binaries.  Static binaries that use NSS (such as your ls binary that
uses getpwuid and the like) have the dynamic linking code linked in
statically (from the same source code that goes into the dynamic linker).
This code loads the nss libraries and their dependencies, including
libc.so.  So you have old 2.2.5 dynamic linking code loading new 2.3 shared
objects.  The bug you are seeing is in the old dynamic linking code, which
cannot handle references to "hidden" version set symbols defined in the
same object.  We fixed that bug in the 2.3 dynamic linking code, and in
fact found it because it was tickled by the unexported compatibility-only
symbols like __ctype_toupper.  It's exactly these symbols that are crashing
the old 2.2.5 dynamic linking code in your static binaries.

If you want to hack your glibc 2.3 build to work around the problem, here
is how to do it: Remove the "compat_symbol" lines from ctype/ctype-info.c
and recompile libc.  This makes those symbols be exported again and that
removes the only cases of this combination of symbols and relocations that
the old dynamic linker code doesn't handle.  It means that link-time
references against those symbols will resolve happily in your libc.so
binary, which is exactly what we don't want for these obsolete symbols.
So this workaround won't go into glibc, but you can use it yourself.  The
Red Hat Linux 8.0 version of glibc (which is otherwise not much modified
from glibc 2.2) has this very workaround, not for the problem of old
static binaries that you are having, but to support old static libraries
(i.e. .a files lying around) that otherwise would have been broken very
late in the Beta test cycle.  Other full-system distributions might make
that choice too, I don't know.