I got this from the bug reports filed.
--------------------------
As u can see in bug report this is a compatibility problem between old libs versus new libs.
Static binaries that uses something old and have the dynamic linking code linked in statically. so in your code, when u compile your code, your code loads old binaries and its dependency(like libc.so or something), so your old dynamic linking code try loading new glibc 2.3 code and link together.
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. Redhat 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.
------------------
So the simple solution will be to remove
"compat_symbol" lines from ctype/ctype-info.c and recompile libc,
and then recompile all your binaries and all and see if it works.
Main Topics
Browse All Topics
by: shivsaPosted on 2003-12-11 at 13:29:20ID: 9923602
did u try the workaround given in bug report.