I believe we will need this patch Roland mentions. It'll: - prevent some crashes from static binaries on the new libc - reduce the need to recompile some static libraries
As Roland says, it's wrong, but not in a very harmful way. I'd suggest putting it in, and then removing it in six months or a year. ----- Forwarded message from Roland McGrath <[EMAIL PROTECTED]> ----- Date: Mon, 7 Oct 2002 00:37:13 -0700 From: Roland McGrath <[EMAIL PROTECTED]> Subject: Re: More info on static binary/libnss* mystery To: Greg Schafer <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] 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 ----- -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
