Bug 86465
| Summary: | Undefined __ctype_b using glibc with ncurses | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | arch harris <service> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | chuck, colin, ddonovan, harald.dunkel, ispsysop, jmyosra, lee.moore1, mitr, peterw, range006, whelan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-04-10 23:09:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
__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. 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? Can you please try ftp://people.redhat.com/jakub/glibc/errata/8.0/ ? *** Bug 87468 has been marked as a duplicate of this bug. *** *** Bug 87468 has been marked as a duplicate of this bug. *** *** Bug 87468 has been marked as a duplicate of this bug. *** Fix verified in glibc-2.3.2-4.80.6. 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. http://rhn.redhat.com/errata/RHSA-2003-089.html Hello, I get __ctype_b missing on Redhat 9.0, this there already a fix for RH 9.0 Winfrid 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). 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. Winfrid 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. Can we have a fix for RH 9 please? We definitely need a fix for RH9, otherwise nobody will upgrade 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). 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. 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. 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); 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 distribution. 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 rest. 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. 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. 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. Is this going to be fixed on RH 9, so I can upgrade? 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. 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? Regards Harri The following article seems to solve my problem (rm/cobol compiler) http://newweb.ices.utexas.edu/misc/ctype.c MGL Does anyone know where I can download glibc 2.3.2-5? I have it now. Now, does anyone know how to downgrade from glibc-2.3.2-95.27 to glibc-2.3.2-5? 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. Dan 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! (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. 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. |
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): glibc.2.3.2-4.80.i686.rpm How reproducible: Always Steps to Reproduce: 1.Create file t.c: #include <curses.h> main () { initscr(); } 2. Compile with: gcc -static t.c -lncurses 3. 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).