Bug 89294 - Undefined symbol ctype_b in glibc.
Undefined symbol ctype_b in glibc.
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-04-22 07:43 EDT by Martin Fuerderer
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-22 07:46:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Martin Fuerderer 2003-04-22 07:43:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

Description of problem:
This problem has already been reported in bug # 86465, but only for
RedHat 8.0 and older. The problem exists in RedHat 9 also.
Up to now,
does not contain a fix for RedHat 9 (only fixes for RedHat 8.0 and

Version-Release number of selected component (if applicable):
glibc 2.3.2

How reproducible:

Steps to Reproduce:
See also bug # 86465.

Additional info:
Comment 1 Jakub Jelinek 2003-04-22 07:46:27 EDT
?? What kind of fix do you expect for RHL9? There is no bug.
The only guaranteed binary compatibility is for (correctly written) shared libraries
and binaries, all .o/.a files/libraries always have to be recompiled in the new
Comment 2 Martin Fuerderer 2003-04-22 08:12:16 EDT
This undefined symbol problem does not exist on SuSE Linux 8.2, even though
they also have distributed glibc 2.3.2.
For the time being I suppose that they have found a better way to support
backward compatibility :-)
It would be nice if RedHat 9 could provide the same level of support.
Comment 3 Gérard Milmeister 2003-05-09 18:53:08 EDT
I recompiled glibc-2.3.2-27.9.src.rpm where I removed 
the lines containing compat_symbol pertaining to the __ctype_b
symbols in files ctype/ctype-info.c and locale/lc-ctype.c. The build
produced only glibc-2.3.2-27.9.i686.rpm and nptl-devel-2.3.2-27.9.i686.rpm.
Is this correct?
Anyway, I absolutely need to have this, because otherwise many development tools
that don't include the source code for their (static) libraries (like ISE's
Eiffel) don't link.
Are there any problems with this solution?
If not, why did RedHat choose to do this? Why break a lot of software like
those development tools?
Comment 4 Jakub Jelinek 2003-05-14 04:13:59 EDT
Any program which uses __ctype_b etc. will not work with uselocale(3) properly.
This is why those symbols has been made compatibility only in the FSF tree
and our rpms as well.
Comment 5 Rob Swindell 2003-06-30 20:59:41 EDT
I am the maintainer of an open source project that distributes pre-compiled 
libraries for several flavors of Unix. The only operating system to date that 
appears to have incompatibilities with these libraries is RedHat Linux 9. I've 
heard (but have not personally verified) that the glibc that comes with the 
boxed version of RH9 works fine, but the downloaded or an "up2date" install of 
RH9 includes a version of glibc that is missing these symbols (ctype_b*).

These libraries simply #include <ctype.h> and use the macros there-in, like 
isalpha(), toupper(), etc. They do not use uselocale(). In addition, if the 
libraries are built on RHL9, they do not work on any other distros or RHL 
versions (undefined reference to `__ctype_b_loc' among many other errors).

This appears to me, to be an unacceptable scenario and am dissapointed to find 
this bug "closed" and marked "notabug". I disagree with this conclusion and 
request that you reevaluate this bug.

Until this bug is fixed, I have no alternative than to simply not support RHL9, 
or require users to build their own libraries from source (which is not a 
disireable solution).

Thank you,
Comment 6 Ronald Cole 2003-07-27 21:17:25 EDT
I think the problem is that there is no __ctype_b@ defined in libc to bind an 
unspecified base version to.  That would break backwards compatibility since 
an old library would have no idea that it should have been defined as 
__ctype_b@GLIBC_2.0 to work properly in the future.  FYI, the other two 
symbols in libc I'm having this problem with are: __ctype_toupper and 
__ctype_tolower.  Red Hat may not consider this a "bug", but backwards 
compatibilty where it's simply a matter of adding the proper symbol version 
info is not only a nice gesture, it's the "right thing" to do.

Note You need to log in before you can comment on or make changes to this bug.