This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
More info on static binary/libnss* mystery
- From: Greg Schafer <gschafer at zip dot com dot au>
- To: libc-alpha at sources dot redhat dot com
- Date: Sun, 6 Oct 2002 17:01:45 +1000
- Subject: More info on static binary/libnss* mystery
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