Re: RH glibc and __ctype_b
I'm not sure exactly what you are asking.
What makes old static binaries crash when they try to load a new libc.so is
an old bug in the dynamic loading code when handling a reference within an
object to a hidden symbol in the same object. That was fixed by this change:
2002-09-18 Roland McGrath <roland@redhat.com>
* elf/do-rel.h (elf_dynamic_do_rel): Mask off 0x8000 bit (hidden flag)
from the value taken from the DT_VERSYM table.
* elf/dl-runtime.c (fixup, profile_fixup): Likewise.
* sysdeps/mips/dl-machine.h (__dl_runtime_resolve): Likewise.
(RESOLVE_GOTSYM): Likewise.
Obviously, existing static binaries will continue to have that bug. It
makes them crash when they come across such a symbol. In stock 2.3.1,
__ctype_b et al are such symbols because they are not exported at link time.
The compat_symbol uses are what prevent the link-time export (in nm output,
you can see __ctype_b@GLIBC_2.0 vs __ctype_b@@GLIBC_2.0 and the like;
in objdump --dynamic-syms output you can see "GLIBC_2.0" vs "(GLIBC_2.0)").
In the RHL version of glibc, those symbols are exported again by omitting
the compat_symbol uses. The both avoids tickling the aforementioned bug,
and also lets existing .a's and .o's compiled with the old ctype.h be
usable. If you want to do that, just comment out the compat_symbol's.
Reply to: