Bug 91290 - glibc 2.3.2 --> undefined reference to '__ctype_b'
Summary: glibc 2.3.2 --> undefined reference to '__ctype_b'
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
(Show other bugs)
Version: 9
Hardware: All Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
: 146285 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-20 20:45 UTC by Chandrasekar Ram
Modified: 2016-11-24 15:18 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-15 08:24:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Chandrasekar Ram 2003-05-20 20:45:05 UTC
Description of problem:

When I run a 'make' to my application I get the following error...
/home/.../lib/libldapssl41.so: undefined reference to '__ctype_b'
/home/.../lib/libldapssl41.so: undefined reference to '__ctype_tolower'
/home/.../lib/libldapssl41.so: undefined reference to '__ctype_toupper'
collect2: ld returned 1 exit status

I have added the path '/home/.../lib' to LD_LIBRARY_PATH, but still this doesnt 
seem to work.  I found a similar bug report at 

Everything was working fine until I upgraded to "RedHat 9.0"

So is this a problem with glibc version 2.3.2...Please Help...

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Conrad Whelan 2003-05-21 19:36:11 UTC
This is a similar bug to 86465.  That one was solved or v8.0.

Comment 2 Werner Puschitz 2003-05-30 14:16:42 UTC
I think this bug made a comeback. I'm getting the same errors when I install
Oracle9i on RH 9. Bug 86465 said that a fix was verified in glibc-2.3.2-4.80.
Here is the reason why some people have this problem with RH 9 and why some don't.

The RH 9 CDs that you can buy in the stores come with glibc-2.3.2-5 and
glibc-devel-2.3.2-5. With this version I don't get these erros.

The RH 9 images that are available for download at redhat.com and at the mirror
sites come with glibc-2.3.2-11.9 and glibc-devel-2.3.2-11.9. When I use this
glibc version, then I have this problem. I'm also having this problem with the
latest glibc version 2.3.2-27.9.


Comment 3 Rob Swindell 2003-07-02 21:38:25 UTC
I too have this problem with libraries built with RH8 and older. And I don't 
buy the "not a bug" response I've seen so far from RedHat.


Comment 4 Tiago Quintino 2003-07-03 16:16:40 UTC
This BUG had another version for RH8 and older distributions as BUG 86465,
marked as solved. On BUG 86465 comments, people have been writting about not
being able to compile with INTEL compilers or running prgrams like Tecplot.

I am running RH9 installed with all updates.
I have experienced problems running Tecplot 9.0 and 9.2.

With following error message:

relocation error: /usr/local/tecplot9/lib/mesa/libtec.so: symbol errno, version
GLIBC_2.0 not defined in file libc.so.6 with link time reference

I have experienced problems compiling with Intel ICC 7.1.

As expected, the same error appeared:

/opt/intel/compiler70/ia32/lib/libcprts.a(xlocinfo.o)(.text+0x8b): In function
: undefined reference to `__ctype_b'

I am currently running glibc 2.3.2-27.9.

How come the BUG is solved for RH8 and not for RH9????

Comment 5 Chandrasekar Ram 2003-07-03 17:05:20 UTC
relocation error: /usr/local/tecplot9/lib/mesa/libtec.so: symbol errno, version
GLIBC_2.0 not defined in file libc.so.6 with link time reference <-- This error 
can be temporarily fixed by setting the environment variable 
LD_ASSUME_KERNEL=2.4.1, but i wouldnt say this is  permenant fix.

and for the `__ctype_b' error, RedHat had a fix for 8.0, but they still dont 
have a fix for 9.0.  and __ctype_b seems to be a backward compatibility bug, 
someone is using __ctype_b instead of __ctype_b_loc with the new locale thing, 
so i guess if we find who's referencing it and change that reference or create 
a dummy where __ctype_b_loc is defined to translate to __ctype_b, this can be 
solved.  but i'm not sure though.  

Comment 6 Jakub Jelinek 2003-07-15 08:24:14 UTC
RHL9 and later is not going to be changed.
The change was done on purpose.
Binary compatibility in Linux is always guaranteed for just
binaries and shared libraries accross releases, never .o files
nor .a files. They have to be recompiled.
This is how symbol versioning works, compilation needs to be done
against glibc headers from glibc which is used during final link
(new incompatible interfaces through symbol versioning are introduced
pretty often, and old binaries/shared libraries will work because
the old symbol is exported as symbol@old_symbolversion; but
.o/.a files don't have symbol versions attached, so they always
pick up the default symbol version (ie. symbol@@new_symbolversion)
which does not have to be the function against which the object
was compiled).
For __ctype_b*, the decision to replace it by __ctype_b_loc etc.
and disallow any new links against the old type were made because
__ctype_b* does not work together with uselocale(3).
These days, uselocale(3) is used quite often e.g. in libstdc++,
so it is very bad idea to keep using __ctype_b etc.
In RHEL3, there will be compat-glibc package which you can link
against (provided the objects were compiled on RHEL 2.1), but it
is highly recommended to recompile all the objects against glibc 2.3.2
RHL8 was different, the change was introduced accidentally in an errata,
but there were many already compiled .a libraries shipped with that release,
so in subsequent errata this was changed back.

Comment 7 Rob Swindell 2003-07-16 02:41:57 UTC
Okay, then can you please explain why this "non-bug" is effecting .so files as 

libjs.so: undefined reference to `__ctype_b'
collect2: ld returned 1 exit status

This shared library was built with an older version of RHL and does not link 
with glibc-2.3.2-27. This symbol does not appear to be symbol-versioned.

A similar error (reference to '__ctype_b_loc') occurs when attempting to link 
a .so file generated with glibc-2.3.2-27 on a system with an older glibc.

Does this have to do with how the shared libarary is created?

Would using gcc instead of ld fix this issue?

More information would be appreciated, as simply "using .so's insted of .a's" 
does not appear to be the answer.

Thank you very much,


Comment 8 Rob Swindell 2003-07-16 02:58:13 UTC
Preliminary results are in: linking with gcc instead of ld appears to allow 
foward-compatibility for .so files at least (old .so's work with the new glibc).


Comment 9 James Patton 2003-10-08 07:11:09 UTC
Dear Support,

Re: Lahey Fortran95 Linux Express v6.1/v6.2 and glibc 2.3.x

Users of my Redhat 9.0 Linux server (with glibc-2.3.2-27.9) cannot 
link code (that was linking until recently unchanged), due to
undefined references to __ctype_tolower and __ctype_b.

In the on-going bid to get Lahey Fortran95 to work with Red Hat 9
and glibc2.3 I downloaded  and installed the trial version of LF95 v6.2.

I also upgraded the Red Hat 9 glibc libraries to glibc-2.3.2-27.9, which 
are supposed to be backward compatible with older versions of glibc,
and to put back support for __ctype_lower and __ctype_b.
The url is: http://rhn.redhat.com/errata/RHBA-2003-136.html.

Unfortunately, during installation of Lahey Fortran95 I 
received the following warning:

LF95 v6.2 has been tested for compatibility with glibc2.2.
Results are not guaranteed when used with other versions
of the runtime libraries.

The install was unable to find an LF95 compatible version of
glibc on this system.

Do you wish to continue with the LF95 installation? [n] yes

During linking the Fortran program we still get the following errors:

/usr/local/lf9562/bin/../lib/libfj9i6.a(jwe_iedi.o)(.text+0xfb6): In function 
: undefined reference to `__ctype_b'
/usr/local/lf9562/bin/../lib/libfj9i6.a(jwe_iedi.o)(.text+0xfc2): In function 
: undefined reference to `__ctype_tolower'

If we downgrade the glibc libraries back to glibc2.2, will
this break other things in RH9?

Does Lahey have a patch for glibc 2.3.x support?

Any suggestions appreciated,


 http://www.lahey.com/linux.htm says 
 Red Hat v9.0 2.4.20-6 libc 2.3.2 is a supported platform on LF95 v6.2.
 Is this true?

Also see:

Comment 10 BOMAN Romain 2003-11-28 13:55:11 UTC
Try to use "-i_dynamic" at link time.
It works (I use RedHat 9 (no patch) - icc-7.0)

Comment 11 David Sagan 2004-02-02 21:55:35 UTC
Dear Support:

I also have the problem with undefined references with Lahey Fujitsu Fortran 95 as 
seen in comment #9. I link with the lf95 command but there is no "-i_dynamic" switch 
with this command. What can I do? Also: what does -i_dynamic do? Will it conflict with 
static compiling?

                     -- Thanks for any help, David Sagan

Comment 12 Mona Hobby 2004-02-13 21:22:05 UTC
Dear Support:

I tried to use "-i_dynamic" at link time, and it did NOT work for 
me.  I am using gcc.

-- Please help!, Mona Hobby

Comment 13 Ade Lewis 2004-03-11 16:12:48 UTC
Ok, someone quickly run through this to answer all my questions of the
same issue:

1 - There was a conscious attempt to break the linking of pre-libc6.3
code with libc6.3 code [True/False] ?
2 - Was done by the [GNU team/Redhat|Fedora teams] ?
3 - This is ["the way forward now"/"Broken and to be fixed"] ?
4 - If you want to do this, you are ["able to with a simple RPM
install work around that works/Not able to do this and no simple RPM
install work around exists"] ?

Thats a summation of my questions. 
Sorry, but your comments above left me a little in the dark about a
fix/not a bug/expected behavour. I'm new to this problem and have to
answer to people and explain these points to them. 

I'd like some clarity before I tell people to use Debian or FreeBSD
until this is resolved as I currently feel uneasy pushing them down
that road (they have no means of building all the libraries, as its
partially 3rd party stuff).

Comment 14 Jakub Jelinek 2004-03-11 16:23:52 UTC
1) False, the change was necessary to make the new locale model working
2) The change was done in the upstream glibc, i.e. GNU team
3) It is a way forward now
4) you can use compat-glibc rpm to work around it.  You can find
   compat-glibc in RHEL3
If 3rd party stuff is shipped as .a libraries instead of shared libraries,
it is relying on a kind of binary compatibility which has never
been guaranteed.

Comment 15 steve 2004-04-13 19:45:01 UTC
Using compat-glibc to fix this same problem with sqsh-2.1

On a RHEL3ish system I installed compat-gcc-7.3 and compat-glibc-7.x 
and used 

$ CC="gcc296 -I /usr/lib/i386-redhat-linux7/include -B \
/usr/lib/i386-redhat-linux7/lib/" ./configure
$ make
#make install

Comment 16 Jakub Jelinek 2005-01-26 18:40:37 UTC
*** Bug 146285 has been marked as a duplicate of this bug. ***

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