Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 19316
  • Last Modified:

Glibc and the "undefined reference to __ctype_b" error

After installing Redhat 9.0 some older libraries (part of Talarian Smartsockets if you are interested) are no longer working for us.
While linking, the error message "undefined reference to __ctype_b" appears - this is a feature of glibc no longer avaiable in glibc-2.3.2-11.9, but avaiable in glibc-2.2.

To gain a better understanding of the problem you can also read
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91290

I will give points for a detailed description of a solution, those come to mind:

1. Install older version of glibc, i.e. 2.3.2-5, the last version that seems to work. Questions: Will Redhat still work, how to downgrade an installation of glibc
   (parameters to force rpm to install older version?)

2. Parallel install of two glibc versions? Is this even possible?

3. A patch/compatibility addon for the newer version of glibc, I haven't found one but perhaps I have not looked hard enough?

Please try to give a detailed description of the solution, I'm still a bit shaky when it comes to managing libraries and dependencies in Linux.
0
Wojciech Duda
Asked:
Wojciech Duda
  • 2
1 Solution
 
shivsaCommented:
did u try the workaround given in bug report.
0
 
shivsaCommented:
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.
0
 
Wojciech DudaAuthor Commented:
Well, while I don't know if this will be a working solution for us (as we'll have to always use the modified glibc version), this workaround description is a vaiable solution and I'll try this. Thanks for your input.
0

Featured Post

Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now