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 http://www.redhat.com/archives/redhat-list/2003-May/msg01559.html 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): glibc-2.3.2-11.9 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is a similar bug to 86465. That one was solved or v8.0.
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. Werner
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. -Rob
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 `_Getctyptab': : 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????
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.
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 instead. 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.
Okay, then can you please explain why this "non-bug" is effecting .so files as well? 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, -Rob
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). -Rob
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 `jwe_iiie': : undefined reference to `__ctype_b' /usr/local/lf9562/bin/../lib/libfj9i6.a(jwe_iedi.o)(.text+0xfc2): In function `jwe_iiie': : 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, James. PS: 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: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86465 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91290
Try to use "-i_dynamic" at link time. It works (I use RedHat 9 (no patch) - icc-7.0)
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
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
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).
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.
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
*** Bug 146285 has been marked as a duplicate of this bug. ***