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

Greg Schafer gschafer at zip.com.au
Mon Oct 7 01:06:28 PDT 2002

----- Forwarded message from Roland McGrath <roland at redhat.com> -----

Date: Mon, 7 Oct 2002 00:37:13 -0700
From: Roland McGrath <roland at redhat.com>
To: Greg Schafer <gschafer at zip.com.au>
Cc: libc-alpha at sources.redhat.com
Subject: Re: More info on static binary/libnss* mystery

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.

----- End forwarded message -----
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