Forum OpenACS Q&A: Re: Installing Oracle 8.1.7 on Red Hat 9
Posted by
Guan Yang
on 06/06/04 12:06 PM
Jeff: Is that a solution to my problem with the __ctype_b undefined references?
One note: I haven't installed compat-glibc-6.2-2.1.3.2.i386.rpm (which is actually from Red Hat 7.3). Is this package necessary? And where exactly should __ctype_b be defined?
It would be cool if we had a database of successful OpenACS installs with Linux distribution, database version, etc., so I could verify that this combination actually exists in production environments. I really don't want to go back to Red Hat 8.0.
Posted by
Jeff Davis
on 06/06/04 12:29 PM
Yeah, your problem. Here is the relevant section
from his writeup:
The issue here is that __ctype_b() is actually gone for __ctype_b_loc() because Red Hat uses a new locale model. However, in libc.so, __ctype_b is still exported as compatibility symbol; at least that's the case with RH 9 glibc-2.3.2-5. And here is the reason why some people have this problem with Red Hat 9 and why some don't:
When you bought the Red Hat 9 CDs in a store, then you will probably find glibc-2.3.2-5.i686.rpm on the first CD. This glibc version exports __ctype_b():
Check the glibc version on your system:
First check if the glibc packages on your RH 9 system work with the Oracle installer:
But if your system has the 2.3.2-5 glibc versions installed, then you are fine and you don't need to follow the described "Work Around" procedure!
Work Around Procedure:
Since I was not able to find the glibc-2.3.2-5 RPMs available for download, I'm making the RPMs available on my website. These RPMs are copies of the glibc RPMs that came with the RH 9 CDs I bought in the store. I do not recommend to use any of the "compat" RPMs from older Red Hat distributions since RH 9 contains major changes.
Here is the procedure for installing glibc-2.3.2-5 temporarely on your RH 9 server:
Download the 2.3.2-5 glibc RPMs from here on my web site.
First make sure if these downloaded RPM's are not corrupt and if they were really built and signed by Red Hat. You never know if someone fiddled with these RPMs or replaced them. To ensure the integrity and origin of these Red Hat's RPMs, run the following commands:
Now try to run runInstaller again.
After Oracle has been installed, you can upgrade glibc, glibc-common, and glibc-devel again. For example:
According to Red Hat, binary compatibility in Red Hat Linux is always guaranteed for binaries and shared libraries accross releases, but not for .o files nor .a files. However, compatibility is guaranteed for .o files and .a files. _within_ a realease. Since glibc-2.3.2-5 and glibc-2.3.2-11.9 are from the same release, compatibility should be guaranteed for .o files (Oracle's .o files which have been created during the Oracle installation) and .a files.
This means that Oracle should be fine when you upgrade glibc after the Oracle installation.
... /opt/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln.o)(.text+0x159d): In function `Nls_ScanCmd': undefined reference to `__ctype_b' /opt/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln.o)(.text+0x1603): more undefined references to `__ctype_b' follow
The issue here is that __ctype_b() is actually gone for __ctype_b_loc() because Red Hat uses a new locale model. However, in libc.so, __ctype_b is still exported as compatibility symbol; at least that's the case with RH 9 glibc-2.3.2-5. And here is the reason why some people have this problem with Red Hat 9 and why some don't:
When you bought the Red Hat 9 CDs in a store, then you will probably find glibc-2.3.2-5.i686.rpm on the first CD. This glibc version exports __ctype_b():
$ 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 $But when you downloaded Red Hat 9 from redhat.com or from one of the mirror sites, then you will find glibc-2.3.2-11.9.i686.rpm on the image. This glibc version does not export __ctype_b(). This is also the case with glibc-devel-2.3.2-27.9.i386.rpm.
$ 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 $
Check the glibc version on your system:
First check if the glibc packages on your RH 9 system work with the Oracle installer:
$ rpm -q glibc-2.3.2-5 glibc-common-2.3.2-5 glibc-devel-2.3.2-5If you got the following error mesages:
package glibc-2.3.2-5 is not installed package glibc-common-2.3.2-5 is not installed package glibc-devel-2.3.2-5 is not installedthen you have glibc packages on your system that don't work with the Oracle installer and you need to follow the "Work Around" procedure here.
But if your system has the 2.3.2-5 glibc versions installed, then you are fine and you don't need to follow the described "Work Around" procedure!
Work Around Procedure:
Since I was not able to find the glibc-2.3.2-5 RPMs available for download, I'm making the RPMs available on my website. These RPMs are copies of the glibc RPMs that came with the RH 9 CDs I bought in the store. I do not recommend to use any of the "compat" RPMs from older Red Hat distributions since RH 9 contains major changes.
Here is the procedure for installing glibc-2.3.2-5 temporarely on your RH 9 server:
Download the 2.3.2-5 glibc RPMs from here on my web site.
First make sure if these downloaded RPM's are not corrupt and if they were really built and signed by Red Hat. You never know if someone fiddled with these RPMs or replaced them. To ensure the integrity and origin of these Red Hat's RPMs, run the following commands:
$ su - root # rpm --import /usr/share/rhn/RPM-GPG-KEY # add Red Hat's PGP public key to the RPM database # rpm --checksig glibc-2.3.2-5.i686.rpm glibc-common-2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpm glibc-2.3.2-5.i686.rpm: (sha1) dsa sha1 md5 gpg OK glibc-common-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK glibc-devel-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK #Downgrade glibc, glibc-common, and glibc-devel:
# rpm -Uvh --oldpackage glibc-2.3.2-5.i686.rpm glibc-common-2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpmIf you get the following error:
error: Failed dependencies:
glibc = 2.3.2-11.9 is needed by (installed) glibc-debug-2.3.2-11.9
glibc = 2.3.2-11.9 is needed by (installed) glibc-utils-2.3.2-11.9
glibc-devel = 2.3.2-11.9 is needed by (installed) glibc-debug-2.3.2-11.9
glibc-devel = 2.3.2-11.9 is needed by (installed) nptl-devel-2.3.2-11.9
then you can temporarily remove these RPMs (glibc-debug, glibc-utils,
nptl-devel) from your system until you upgrade the glibc RPMs after
your Oracle installation:
# rpm -e glibc-debug glibc-utils nptl-devel
Now try to run runInstaller again.
After Oracle has been installed, you can upgrade glibc, glibc-common, and glibc-devel again. For example:
# rpm -Uvh glibc-2.3.2-11.9.i686.rpm glibc-common-2.3.2-11.9.i386.rpm glibc-devel-2.3.2-11.9.i386.rpm
According to Red Hat, binary compatibility in Red Hat Linux is always guaranteed for binaries and shared libraries accross releases, but not for .o files nor .a files. However, compatibility is guaranteed for .o files and .a files. _within_ a realease. Since glibc-2.3.2-5 and glibc-2.3.2-11.9 are from the same release, compatibility should be guaranteed for .o files (Oracle's .o files which have been created during the Oracle installation) and .a files.
This means that Oracle should be fine when you upgrade glibc after the Oracle installation.
