Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: Relinking Oracle 9iR2 fails on RedHat 9 [root@swalker bin]# ./relink client_sharedlib /opt/oracle/bin/genclntsh /opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0x74): In function `kgupdpg': : undefined reference to `__ctype_b' /opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0xb9): In function `kgupdpg': : undefined reference to `__ctype_b' /opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0x10a): In function `kgupdpg': : undefined reference to `__ctype_b' /opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0x14a): In function `kgupdpg': : undefined reference to `__ctype_b' /opt/oracle/lib/libclient9.a(kudmi.o)(.text+0x3772): In function `kudmchs': : undefined reference to `__ctype_toupper' /opt/oracle/lib/libclient9.a(kudmi.o)(.text+0x3791): In function `kudmchs': : undefined reference to `__ctype_b' /opt/oracle/lib/libclient9.a(kudmi.o)(.text+0x37c2): In function `kudmchs': : undefined reference to `__ctype_toupper' .... And so on. Relinking under RedHat 8 worked fine. Are there different libraries or a different way I need to relink it now? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. edit gencltnsh script to link against -lgcc properly 2. run link script 3. see linker fail with undefined symbols to "__ctype_b", etc. Additional info:
The good news is that copying an installation of the client from an existing RedHat 8.x system allows me to run the client and use the OCI libraries in my local development (thankfully). This issue just prevents me from doing an installation directly on my box using the Oracle installer. (Since I can't relink the libraries).
This is a bug in Oracle (the way they are relinking stuff is inherently error-prone, they have been bitten by this already once (with IPC) and have not changed their install process yet). Please report this to Oracle instead.
Thanks for the information, more of an FYI than anything. I figured as much, has RedHat suggested a better linking solution to them?
But it's interesting that the RH 9 CDs I bought work fine with Oracle9iR2. These CDS come with glibc-2.3.2-5. And the images that are available for download come with glibc-2.3.2-11.9. The glibc-2.3.2-5 exports __ctype_b as compatibility symbol, but glibc-2.3.2-11.9 doesn't. $ rpm -ql glibc-2.3.2-5 | grep libc.so /lib/i686/libc.so.6 /lib/libc.so.6 /lib/tls/libc.so.6 $ nm -a /lib/i686/libc.so.6 | grep __ctype_b 001315f8 D __ctype_b 00022340 T __ctype_b_loc $ nm -a /lib/libc.so.6 | grep __ctype_b 00133c58 D __ctype_b 000223a0 T __ctype_b_loc $ $ rpm -ql glibc-2.3.2-11.9 | grep libc.so /lib/i686/libc.so.6 /lib/libc.so.6 /lib/tls/libc.so.6 $ nm -a /lib/i686/libc.so.6 | grep __ctype_b 00131718 D __ctype_b@GLIBC_2.0 000223a0 T __ctype_b_loc $ nm -a /lib/libc.so.6 | grep __ctype_b 00133d58 D __ctype_b@GLIBC_2.0 000223f0 T __ctype_b_loc $ So why has Red Hat suddenly changed this in Red Hat 9 between glibc-2.3.2-5 and glibc-2.3.2-11.9? Werner
What's the status on this? Why has Red Hat suddenly changed this in Red Hat 9 between glibc-2.3.2-5 and glibc-2.3.2-11.9? And will Red Hat exports __ctype_b as compatibility symbol again? Or should I open a new ticket? Werner
I am sure I have seen the answer to this query elsewhere in bugzilla. The reasoning (if I remember correctly) is that the __ctype_b isn't safe in the TLS environment, so they removed it to discourage people from using it. Hence don't expect it to reappear, though it is apparently quite easy to modify the glibc source to turn the exporting back on.
See http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00093.html for information on how to modify the glibc source so the symbols work again. Also the problem is with uselocale, not TLS.
The point is that they're internal symbols and no sane application should be using them anyway.