Bug 86465 - Undefined __ctype_b using glibc with ncurses
Summary: Undefined __ctype_b using glibc with ncurses
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
: 87468 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-23 03:03 UTC by arch harris
Modified: 2009-04-21 16:36 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-10 23:09:25 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:089 0 high SHIPPED_LIVE : Updated glibc packages fix vulnerabilities in RPC XDR decoder 2003-04-10 04:00:00 UTC

Description arch harris 2003-03-23 03:03:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
After applying the march 19 glibc security update to redhat 8.0, attempts to
link statically programs using ncurses (5.2) fail with __ctype_b undefined.

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

How reproducible:

Steps to Reproduce:
1.Create file t.c:

#include <curses.h>
main () { initscr(); }

2. Compile with:

gcc -static t.c -lncurses

Actual Results: 
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libncurses.a(lib_tparm.o): In
function `parse_format':
lib_tparm.o(.text+0x1112): undefined reference to `__ctype_b'
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libncurses.a(lib_tputs.o): In
function `tputs':
lib_tputs.o(.text+0x213): undefined reference to `__ctype_b'
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libncurses.a(lib_mvcur.o): In
function `_nc_msec_cost':
lib_mvcur.o(.text+0xa5): undefined reference to `__ctype_b'
collect2: ld returned 1 exit status

Expected Results:  No link errors.

Additional info:

This problem did not exist prior to uploading the March 19 glibc patch.

This probably causes programs using ncurses that are dynamically linked to crash
(if so, I suppose that would raise the severity level).

Comment 1 Jakub Jelinek 2003-03-24 14:03:53 UTC
__ctype_b is gone for *__ctype_b_loc() because of the new locale model.
In libc.so, __ctype_b is exported as compatibility symbol, but for the 8.0
errata it should be readded to libc.a.

Comment 2 Axel Thimm 2003-03-26 07:47:46 UTC
This bug can be seen in many other scenarios, too, for example when trying to
rebuild rpm from source libbz2 bails out:

   /usr/lib/libbz2.a(bzlib.o): In function `bzopen_or_bzdopen':
   bzlib.o(.text+0x27ce): undefined reference to `__ctype_b'

Using nm on /usr/lib/*.a gives ~700 instances of undefined __ctype_b. Probably
any more complex build process involving static libraries will hit this bug
(e.g. packaging rpms).

What is the right way to readd these symbols (is it only __ctype_b or maybe
more?) to libc.a?

Comment 3 Jakub Jelinek 2003-03-26 17:46:27 UTC
Can you please try ftp://people.redhat.com/jakub/glibc/errata/8.0/ ?

Comment 4 Daniel Veillard 2003-03-27 15:20:30 UTC
*** Bug 87468 has been marked as a duplicate of this bug. ***

Comment 5 Daniel Veillard 2003-03-27 23:17:33 UTC
*** Bug 87468 has been marked as a duplicate of this bug. ***

Comment 6 Daniel Veillard 2003-03-28 00:06:21 UTC
*** Bug 87468 has been marked as a duplicate of this bug. ***

Comment 7 Brian Brock 2003-04-10 21:31:46 UTC
Fix verified in glibc-2.3.2-4.80.6.

Comment 8 Jakub Jelinek 2003-04-10 23:09:25 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


Comment 9 Winfrid Tschiedel 2003-05-05 13:04:31 UTC

I get __ctype_b missing on Redhat 9.0, this there already a fix for RH 9.0


Comment 10 Jakub Jelinek 2003-05-05 13:07:08 UTC
On RHL9 this is not a bug. There is no binary compatibility for .a libraries
or .o files between distribution major releases (glibc only ensures
binary compatibility for programs and shared libraries using symbol versioning,
for static libraries this cannot work).

Comment 11 Winfrid Tschiedel 2003-05-05 13:21:37 UTC
Hello Jakub,

Personally I do not have any problems with your answer, that the new version is 
not compatible with glibc 2.2.x, but currently the incompatibility causes a 
link trouble for Intel's fortran95 under RedHat 9.0. Intel is informed about 
the trouble but they are very slow in fixing it.


Comment 12 Jakub Jelinek 2003-05-05 13:25:48 UTC
The change was done in glibc on purpose. If __ctype_b etc. are used, programs
or libraries using uselocale(3) might be doing the wrong thing.

Comment 13 Colin Adams 2003-05-14 19:48:57 UTC
Can we have a fix for RH 9 please?

Comment 14 Need Real Name 2003-05-19 15:10:54 UTC
We definitely need a fix for RH9, otherwise nobody will upgrade

Comment 15 Kevin Range 2003-05-21 17:53:59 UTC
I have to agree with those people asking for a fix in RH9.  Our lab has been
using RedHat for 5 years now, but this bug is causing people to actaully
DOWNGRADE new machines to RedHat 8 or 7.3.  Come Dec. when 8/7.x is EOL, we may
have to move to another distrobution if this bug is not resolved by RedHat
and/or f95 compiler vendors (NAG and Intel).

Comment 16 Eric Sandall 2003-05-21 18:49:27 UTC
Our high-end compilers (Lahey, Absoft, etc.) no longer work, nor does Tecplot. 
These programs are crucial to our work.

I see mention of this bug on numerous lists and some seem like they say it is
fixed in the latest glibc updates (I am running RH 9, glibc-2.3.2-27.9), but I
have no such luck.

Comment 17 Conrad Whelan 2003-05-21 19:47:01 UTC
I am also running RH9, with similar problems.  I noticed that there is a bug
numbered 91290 dealing with the same issue, except dedicated to RH9.  It is
currently high priority, and I hope it gets fixed soon so I can compile my
Fortran once again.

Comment 18 arch harris 2003-05-21 21:18:36 UTC
I find these reports of problems interesting because when I upgraded to
RH9 and recompiled, the problems disappeared.  While still using RH8.0, I
added the following "bug workaround" file and it appeared to solve the problem
(although it did not get a lengthy test since shortly therefter I upgraded to
RH9 and no longer needed it).  The bug workaorund that I used on RH8 is provided
below in case it helps those of you having problems with RH9.

 * ctype_b.c
 * This file has been added to compensate for a bug in
 * version 2.3.2 of the glibc library for RH8.
#define attribute_hidden
#define CTYPE_EXTERN_INLINE /* Define real functions for accessors.  */
#include <ctype.h>
#include <locale/localeinfo.h>
__libc_tsd_define (, CTYPE_B)
__libc_tsd_define (, CTYPE_TOLOWER)
__libc_tsd_define (, CTYPE_TOUPPER)
#include <shlib-compat.h>
#define b(t,x,o) (((const t *) _nl_C_LC_CTYPE_##x) + o)
extern const char _nl_C_LC_CTYPE_class[] attribute_hidden;
extern const char _nl_C_LC_CTYPE_toupper[] attribute_hidden;
extern const char _nl_C_LC_CTYPE_tolower[] attribute_hidden;
const unsigned short int *__ctype_b = b (unsigned short int, class, 128);
const __int32_t *__ctype_tolower = b (__int32_t, tolower, 128);
const __int32_t *__ctype_toupper = b (__int32_t, toupper, 128);

Comment 19 Eric Sandall 2003-05-21 21:29:22 UTC
Recompiled what?  glibc?  Recompiling a library is not a valid (IMO) answer to
fix a bug in a _binary_ distribution, if I wanted to do that I'd use a source

However, if I have the time I will try it out (I'm not saying it's a _bad_
solution, just not one that RH should accept ;)), but I've found
patches/workarounds for most of the programs we use here, still looking for the

Comment 20 Colin Adams 2003-05-22 05:31:07 UTC
My problem is with Eiffel Software's Eiffel compiler. I can't link any programs
at all.

So I'm having to await delivery of a new machine, so I can install RedHat 8.0 on it.

Comment 21 arch harris 2003-05-22 05:58:47 UTC
Sorry about the lack of clarity in #18.  I recompiled the program I had written
that I could not compile with the -static option on RH8 (a linux tax preparation
program).  The program compiled fine on RH9.  I did not recompile glibc.

Comment 22 Eric Sandall 2003-05-22 15:44:12 UTC
Ahh, okay.  Did the '-static' option still work?  One of the compilers we use
(Lahey F95) had a patch on their site for glibc 2.3.x support and after applying
this it would compile, but not statically.  The other compilers still have problems.

Comment 23 Colin Adams 2003-07-07 06:30:35 UTC
Is this going to be fixed on RH 9, so I can upgrade?

Comment 24 Jakub Jelinek 2003-07-15 08:07:53 UTC
On RHL9 and later it is going to stay the way it is, ie. forcing all incompatible
objects to be recompiled.
The reason is e.g. libstdc++, which extensively uses uselocale these days,
and __ctype_b using objects don't work together with uselocale (that's why
__ctype_b_loc etc. were introduced).
Binary compatibility is maintained for shared libraries and binaries only
accross releases, so what you're trying to accomplish was never guaranteed
to work between any releases.

Comment 25 Harri 2003-07-18 17:32:50 UTC
According to http://www.puschitz.com/InstallingOracle9i.shtml the official
RedHat 9 box sold in the stores contains glibc 2.3.2-5, which seems to provide
the __ctype_b symbol and some other symbols that have been dropped for 2.3.2-11.
Using this environment based upon glibc 2.3.2-5 and the appropriate development
libraries, would it be possible to build a static or dynamic library that cannot
be linked on a RedHat 9 system with glibc-2.3.2-11 or later installed?



Comment 26 Maurice Lafleur 2004-03-10 21:44:31 UTC
The following article seems to solve my problem (rm/cobol compiler)


Comment 27 Daniel Donovan 2004-12-06 15:46:50 UTC
Does anyone know where I can download glibc 2.3.2-5?

Comment 28 Daniel Donovan 2004-12-07 11:29:00 UTC
I have it now.

Now, does anyone know how to downgrade from glibc-2.3.2-95.27 to 

Another way to solve my problem would be to have multiple versions of 
glibc installed. I have tried using rpm using the --relocate and --
prefix options but the package I have is not relocateable.


Comment 29 yosra 2009-04-21 10:09:55 UTC
when I'm compliling my program I have this : (.text+0x8daf): undefined reference to `__ctype_b'
collect2: ld returned 1 exit status
I'm using fedora release 7. please what can I do in this case? which version of glibc must I downolad? 
thank you. best regards!

Comment 30 Axel Thimm 2009-04-21 10:49:26 UTC
(In reply to comment #29)
> when I'm compliling my program I have this : (.text+0x8daf): undefined
> reference to `__ctype_b'
> collect2: ld returned 1 exit status

Check the dates and the bug history, this bug was fixed 6 years ago!

> I'm using fedora release 7. please what can I do in this case? which version of
> glibc must I downolad? 

Upgrade to a newer Fedora, currently supported releases are Fedora 9 and Fedora 10, I recommend the latter.

If the problem still exists open a new bug. It is unlikely that this 6 year old bug still persists unnoticed. And even if then the data in this report is very outdated to be in context with a current glibc release, so please file a fresh bug after verifying that the bug exists on Fedora 10. Don't forget to attach a minimal test program, the command you used to invoke the build and the screen for reproduction of the error.

Comment 31 Jakub Jelinek 2009-04-21 16:36:18 UTC
As explained earlier, the above error with contemporary glibc just means that you are trying to link an object file (or *.a library) compiled against a 6+ years old glibc, which is not supported.  You either have to compile/link everything against the glibc the binary only files were compiled against, or you need the source.

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