More info on static binary/libnss* mystery

[Greg Schafer <gschafer at zip dot com dot au>]

Hi

You will recall the problem I reported here:-

http://sources.redhat.com/ml/libc-alpha/2002-10/msg00069.html

whereby statically linked binaries from a 2.2.5 system (that make
calls to libnss*) segfault on a 2.3 system (i686-pc-linux-gnu).

Well, I have narrowed it down to this patch:-


2002-09-05  Roland McGrath  <roland@redhat.com>

       * ctype/ctype-info.c: Renamed __ctype_old_* symbols to __ctype_*.
       * locale/lc-ctype.c (_nl_postload_ctype): Likewise.

Here is the bit from ctype/ctype-info.c for reference:-


===================================================================
RCS file: /cvs/glibc/libc/ctype/ctype-info.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- libc/ctype/ctype-info.c     2002/09/02 07:08:54     1.21
+++ libc/ctype/ctype-info.c     2002/09/05 21:21:48     1.22
@@ -48,18 +48,18 @@

 #define b(t,x,o) (((const t *) _nl_C_LC_CTYPE_##x) + o)

-const unsigned short int *__ctype_old_b = b (unsigned short int, class, 128);
-const __uint32_t *__ctype32_old_b = b (__uint32_t, class32, 0);
-const __int32_t *__ctype_old_tolower = b (__int32_t, tolower, 128);
-const __int32_t *__ctype_old_toupper = b (__int32_t, toupper, 128);
-const __uint32_t *__ctype32_old_tolower = b (__uint32_t, tolower, 128);
-const __uint32_t *__ctype32_old_toupper = b (__uint32_t, toupper, 128);
+const unsigned short int *__ctype_b = b (unsigned short int, class, 128);
+const __uint32_t *__ctype32_b = b (__uint32_t, class32, 0);
+const __int32_t *__ctype_tolower = b (__int32_t, tolower, 128);
+const __int32_t *__ctype_toupper = b (__int32_t, toupper, 128);
+const __uint32_t *__ctype32_tolower = b (__uint32_t, tolower, 128);
+const __uint32_t *__ctype32_toupper = b (__uint32_t, toupper, 128);

-compat_symbol (libc, __ctype_old_b, __ctype_b, GLIBC_2_0);
-compat_symbol (libc, __ctype_old_tolower, __ctype_tolower, GLIBC_2_0);
-compat_symbol (libc, __ctype_old_toupper, __ctype_toupper, GLIBC_2_0);
-compat_symbol (libc, __ctype32_old_b, __ctype32_b, GLIBC_2_0);
-compat_symbol (libc, __ctype32_old_tolower, __ctype32_tolower, GLIBC_2_2);
-compat_symbol (libc, __ctype32_old_toupper, __ctype32_toupper, GLIBC_2_2);
+compat_symbol (libc, __ctype_b, __ctype_b, GLIBC_2_0);
+compat_symbol (libc, __ctype_tolower, __ctype_tolower, GLIBC_2_0);
+compat_symbol (libc, __ctype_toupper, __ctype_toupper, GLIBC_2_0);
+compat_symbol (libc, __ctype32_b, __ctype32_b, GLIBC_2_0);
+compat_symbol (libc, __ctype32_tolower, __ctype32_tolower, GLIBC_2_2);
+compat_symbol (libc, __ctype32_toupper, __ctype32_toupper, GLIBC_2_2);

 #endif


Looks fairly innocuous. So what's the deal here? A compiler bug (gcc-3.2) or
a binutils problem (FSF Release 2.13)? Think I'll try with a newer binutils
and see what happens.

Comments?

Greg