RH glibc and __ctype_b
I'm looking at the changes Red Hat has for __ctype_b (i.e. exporting it and
also not crashing running static binaries). There's something that doesn't
seem to work on Debian but does on Red Hat, and I think I know why. We're
based on 2.3.1+cvs, so we include this patch:
+ /* We need the .symver declarations these macros generate so that
+ our references are explicitly bound to the versioned symbol names
+ rather than the unadorned names that are not exported. When the
+ linker sees these bound to local symbols (as the unexported names are)
+ then it doesn't generate a proper relocation to the global symbols.
+ We need those relocations so that a versioned definition with a COPY
+ reloc in an executable will override the libc.so definition. */
+
+//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);
+
// __ctype_b = current (uint16_t, CLASS, 128);
// __ctype_toupper = current (uint32_t, TOUPPER, 128);
// __ctype_tolower = current (uint32_t, TOLOWER, 128);
Adding the compat_symbol for __ctype32_b here causes glibc 2.2.5 static
binaries to crash.
I see in the .spec changelog that you fixed this problem a different way in
2.2.93-5, but since I can't locate a copy of 2.2.93-4 to compare against I
can't figure out how the fix works. You've got
locale/lc-ctype.c:
extern const uint32_t *__ctype32_b;
__ctype32_b = current (uint32_t, CLASS32, 0);
and ctype/ctype-info.c:
const __uint32_t *__ctype32_b = b (__uint32_t, class32, 0);
compat_symbol (libc, __ctype32_b, __ctype32_b, GLIBC_2_0);
So won't it bind to the wrong copy of __ctype32_b?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: