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, http://rhn.redhat.com/errata/RHSA-2003-089.html does not contain a fix for RedHat 9 (only fixes for RedHat 8.0 and older). Version-Release number of selected component (if applicable): glibc 2.3.2 How reproducible: Always Steps to Reproduce: See also bug # 86465. Additional info:
?? 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 environment.
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 disireable solution). Thank you,
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 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.