Red Hat Bugzilla – Bug 89294
Undefined symbol ctype_b in glibc.
Last modified: 2007-04-18 12:53:12 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):
Steps to Reproduce:
See also bug # 86465.
?? 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
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.
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?
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.
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
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.