Forum OpenACS Q&A: Installing Oracle 8.1.7 on Red Hat 9

Request notifications

Posted by Guan Yang on

I'm trying to install Oracle 8i on Red Hat 9. I've installed the following compat libs:


After installation (which includes some errors from the ins_*.mk makefiles), I extract the glibc-stubs files into $ORACLE_HOME. First of all I've patched so that it won't redirect make output to /dev/null. My immediate problem is that lsnrctl is not linked correctly; then I go in to $ORACLE_HOME/network/lib and try make -f install manually. The following output results:

gcc -L/ora8/m01/app/oracle/product/8.1.7/lib/ -L/ora8/m01/app/oracle/product/8.1.7/rdbms/lib/ -L/ora8/m01/app/oracle/product/8.1.7/network/lib/ -Wl,-rpath,/ora8/m01/app/oracle/product/8.1.7/lib -L/ora8/m01/app/oracle/product/8.1.7/lib/ -L/ora8/m01/app/oracle/product/8.1.7/rdbms/lib/ -L/ora8/m01/app/oracle/product/8.1.7/network/lib/ -o tnslsnr /ora8/m01/app/oracle/product/8.1.7/network/lib/s0nsgl.o /ora8/m01/app/oracle/product/8.1.7/network/lib/snsglp.o -lclntsh /ora8/m01/app/oracle/product/8.1.7/rdbms/lib/kpuadef.o -lnbeq8 -lnhost8 -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8 -lncrypt8 -ln8 -lncrypt8 -lnoname8 -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8 -lntns8 -lnsgr8 -lnzjs8 -ln8 -lnl8 -lnro8 -lnbeq8 -lnhost8 -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8 -lncrypt8 -ln8 -lncrypt8 -lnoname8 -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8 -lntns8 -lnsgr8 -lnzjs8 -ln8 -lnl8 -lclient8 -lvsn8 -lwtc8 -lcommon8 -lgeneric8 -lwtc8 -lmm -lnls8 -lcore8 -lnls8 -lcore8 -lnls8 -lnbeq8 -lnhost8 -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8 -lncrypt8 -ln8 -lncrypt8 -lnoname8 -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8 -lntns8 -lnsgr8 -lnzjs8 -ln8 -lnl8 -lnro8 -lnbeq8 -lnhost8 -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8 -lncrypt8 -ln8 -lncrypt8 -lnoname8 -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8 -lntns8 -lnsgr8 -lnzjs8 -ln8 -lnl8 -lclient8 -lvsn8 -lwtc8 -lcommon8 -lgeneric8 -ltrace8 -lnls8 -lcore8 -lnls8 -lcore8 -lnls8 -lclient8 -lvsn8 -lwtc8 -lcommon8 -lgeneric8 -lnls8 -lcore8 -lnls8 -lcore8 -lnls8 -ldl -lm -lpthread -ldl -lm -lnonc8 -lnl8 -ln8 -lnlsnr8 -lnlsnrc8 -lnsgr8 -lnmd -lnms -lncm8 -lnmsp -lpeer -lnro8 -ln8 -ltrace8 -lnl8 -lnonc8 -lnlsnr8 -lnlsnrc8 -lnmd -lnms -lncm8 -lnmsp -ln8 -lpeer -Wl,-rpath,/ora8/m01/app/oracle/product/8.1.7/lib:/lib:/usr/lib
/ora8/m01/app/oracle/product/8.1.7/network/lib//libnlsnr8.a(nsglsn.o)(.text+0x1276): In function `nsglldprm': : undefined reference to `__ctype_b'
/ora8/m01/app/oracle/product/8.1.7/network/lib//libnlsnr8.a(nsglsn.o)(.text+0x13f4): In function `nsglldprm': : undefined reference to `__ctype_b'
/ora8/m01/app/oracle/product/8.1.7/network/lib//libnlsnr8.a(nsgcs.o)(.text+0x207d): In function `nsgcssr': : undefined reference to `__ctype_b'
collect2: ld returned 1 exit status
make: *** [tnslsnr] Error 1

I get the same output after appending -L/usr/lib/gcc-lib/i386-redhat-linux7/2.96 -lgcc to $ORACLE_HOME/lib/sysliblist and re-running make.

What to do?

Posted by Janine Ohmer on
I'm stuck here too, except mine is in a different place. I'm trying to install 8.1.7 on Redhat Enterprise Server (version 3, I think).

I started up the install, with LD_ASSUME_KERNEL set to 2.2.5 as always. The install stopped with an error linking in At that point I installed the glibc patch, and that let me continue for a bit. But now I'm stuck on, getting the same ctype errors Guan describes.

I found this thread discussing the problem, which doesn't look good...

Has anyone managed to get past this?

Posted by Jeff Davis on
There seems to be a good explanation+solution of this problem here
Posted by Guan Yang on
Jeff: Is that a solution to my problem with the __ctype_b undefined references?

One note: I haven't installed compat-glibc-6.2- (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
Yeah, your problem. Here is the relevant section from his writeup:
  /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, __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
$ nm -a /lib/i686/ | grep __ctype_b
001315f8 D __ctype_b
00022340 T __ctype_b_loc
$ nm -a /lib/ | grep __ctype_b

00133c58 D __ctype_b
000223a0 T __ctype_b_loc
But when you downloaded Red Hat 9 from 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

$ nm -a /lib/i686/ | grep __ctype_b
00131718 D __ctype_b@GLIBC_2.0
000223a0 T __ctype_b_loc
$ nm -a /lib/ | 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-5
If 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 installed
then 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.rpm
If 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.
Posted by Bruno Mattarollo on

I installed Oracle 8.1.7 (and then the patch on a repackaged distribution of RHEL 3.0.

The installation required very little fidling and some hacks that make me think that this way of installing it might not be a production-ready setup but at least it works for OpenACS 5.1 / Oracle 8i on development.

When you install RHEL 3, make sure you have all the compat-* RPMs installed. Before starting runInstaller, make sure you issue export LD_ASSUME_KERNEL=2.2.5 and that you have the glibc-stubs patch from Oracle as well. I also did:

# cd /usr/bin
# mv gcc gcc32
# ln -s gcc296 gcc
before running the installer.

I get the makefile target errors but I ignore them. And the Net8 assistant for the listener also craps out ... killall jre was my friend at that stage but the netca produced all the necessary files.

I also had to copy in $ORACLE_HOME/bin, lsnrctl0 to lsnrctl, tnslsnr0 to tnslsnr and extproc0 to extproc . And then go to $ORACLE_HOME/ctx/bin/ and copy ctxhx0 to ctxhx.

After that, I could start my oracle DB and my listener as well.

Of course, all this assumes that you have modified the kernel parameters as recommended by Oracle, that you have access to a machine already running Oracle 8i just in case, so that you can get the proper working listener.ora and tnsnames.ora in case netca doesn't work for you.

At least this works fine for me ...

Just my 2 cents


Posted by Janine Ohmer on
Thanks, Jeff, that was the sort of info I was looking for.  Unfortunately, I'm not able to install the RPMs from that site on my Enterprise installation.  When I try to just install them as he suggests, I get errors that the existing version is needed by things I can't uninstall even temporarily, like "mount".  And when I try to force the downgrade with --force and --nodeps, I get a bunch of errors like this:

        file /usr/include/wordexp.h from install of glibc-devel-2.3.2-5 conflicts with file from package glibc-headers-2.3.2-95.20

And the packages don't get installed.

The thing I find very odd here is that theoretically I have 2.3.2-95 installed:

[root@abyssinian src]# rpm -qa | grep glibc

Which, as the article you quoted says, is in the same family as the 2.3.2-5 I am trying to install.  So you would think I woudln't even be having this problem....

Moving right along, I found this link

I think this person does more work than they have to;  as far as I can tell, you don't really have to install the compat packages or the Blackdown jre and haven't needed to for quite a while.  But this person claims that if you just continue through all the errors and use the glibc_stubs patch at the end, all will be well.  I guess it's worth a try....

Posted by Janine Ohmer on
Close, but no cigar....

I like to try to find the minimum set of steps needed to do these things, so I didn't install the compat RPMs or any of the other extra steps people mentioned (yet, anyway).

Here are the steps I've followed so far:

  1. make sure LD_ASSUME_KERNEL is set to 2.2.5
  2. run through the install, choosing ignore for all errors
  3. at the second prompt, run and then apply the glibc patch
  4. the Net8 Assistant never comes up, which hangs the install, so kill it at this point
  5. run netca by hand, and kill it again when it hangs because lsnrctl doesn't exist (it needs to be created as Bruno mentioned above)
  6. install patch, choosing ignore for all errors
  7. apply the glibc patch again
  8. run a script to cp and chmod files that are missing or have permissions set wrong (see below)
  9. run dbassist and save files to disk
  10. manually run the first file dbassist creates
Up to this point things were going well; there were no build errors when applying the glibc patch, which (as far as I can tell) gets us past the ctype errors. But now things fall apart with this beauty:

error while loading shared libraries: cannot open shared object file: No such file or directory

This is absolutely correct - that file does not exist. I do have libskgxp8.a, but I don't know how to get from here to there. I found a few threads on this in Google but no answers. There are no errors related to this library in the make log, so I don't think the answer is that a step failed (though I could certainly be wrong).

In fact, after having spent an inordinate amount of time trying to figure out why this file isn't getting built, I realized that I don't have it on any of my other Oracle installations either. They all have just the .a. So now I'm *really* confused. Why would it be looking for a .so on this system when it has obviously never needed one before?

Any suggestions? My next thought is to try changing the gcc version, like Bruno suggested, but I've spent so much time on this already I thought I'd solicit other opinons before spinning my wheels any further.

Here is the script I'm using to fix up the files and permissions, in case anyone else needs it. I created this by comparing the output from "ls -l" on this system and on one of my other ones. This is probably more than actually matters, but since I don't know what many of these programs do I figured it wouldn't hurt to clean things up a bit.

chmod 751 agtctlO
cp agtctlO agtctl
chmod 751 cmadminO
chmod 751 cmgwO
chmod 751 cmctlO
chmod 751 ctxloadO
chmod 751 ctxsrvO
chmod 751 cursizeO
chmod 751 dbfsizeO
chmod 751 dbvO
cp dbsnmpO dbsnmp
chmod 751 exp
chmod 751 extprocO
cp extprocO extproc
chmod 751 hsallociO
cp hsallociO hsalloci
chmod 751 hsdepxaO
cp hsdepxaO hsdepxa
chmod 751 hsotsO
cp hsotsO hsots
chmod 751 imp
chmod 751 kgmgrO
chmod 751 loadpspO
chmod 751 lsnrctlO
cp lsnrctlO lsnrctl
chmod 751 maxmemO
chmod 751 migO
chmod 751 namesctlO
chmod 751 namesO
cp oemeventO oemevent
chmod 751 onrsdO
chmod 751 oracleO
chmod +s oracleO
cp oracleO oracle
chmod 751 orapwdO
cp oratclshO oratclsh
chmod 751 otrccolO
chmod 751 otrccrefO
chmod 751 otrcfmtO
chmod 751 otrcrepO
chmod 751 rman
chmod 751 sbttestO
chmod 751 sqlldr
chmod 751 sqlplusO
chmod 751 svrmgrlO
chmod 751 tkprof
chmod 751 tnslsnr*
chmod 751 tnspingO
chmod 751 trcasstO
chmod 751 trcroute
chmod 751 trcrouteO
chmod 751 tstshmO
chmod 751 wrapO

Posted by Bruno Mattarollo on

I couldn't find the "shared library" version of libskgxp either but I didn't have that error you are mentioning. When do you get that error?

From looking around in the documentation and in metalink, I couldn't find a great deal of information regarding that library, except that it's mentioned in relation to IPC (inter process communication).

Just as a side note, maybe it's related or maybe not, but I didn't install the HTTP server nor the advanced security packages when doing the package selection at installation time.


Posted by Janine Ohmer on
Here's the error:
[oracle@abyssinian bin]$ svrmgrl

Oracle Server Manager Release - Production

Copyright (c) 1997, 1999, Oracle Corporation.  All Rights Reserved.

oraclemuffin: error while loading shared libraries: cannot open shared object file: No such file or directory
oraclemuffin: error while loading shared libraries: cannot open shared object file: No such file or directory
ORA-12547: TNS:lost contact
The listener won't start either, so it's possible that if I fix that, this error will magically go away.

I didn't install http or advanced replication either, or a couple of other things we never use (I forget the exact names now). But I always skip those so it should be ok.

The listener error is more generic:

[oracle@abyssinian bin]$ lsnrctl start

LSNRCTL for Linux: Version - Production on 08-JUN-2004 09:52:55

(c) Copyright 1998 Oracle Corporation.  All rights reserved.

Starting /export/oracle/product/8.1.7/bin/tnslsnr: please wait...

TNS-12545: Connect failed because target host or object does not exist
 TNS-12560: TNS:protocol adapter error
  TNS-00515: Connect failed because target host or object does not exist
   Linux Error: 2: No such file or directory
So I just need to figure out what the msising file or directory is. No problem! :) It could be the same library but I don't think so; that linux error usually happens when trying to directly open a file, not from loading a library.

Posted by Janine Ohmer on
Dang. I got the listener to start; I had overlooked copying tnslsnrO to tnslsnr. But same error from svrmgrl. I get it from sqlplus, too.

Neither of them are linking it in directly:

[oracle@abyssinian bin]$ ldd svrmgrl => /export/oracle/product/8.1.7/lib/ (0xb75e8000) => /export/oracle/product/8.1.7/lib/ (0xb7075000) => /lib/ (0xb7072000) => /lib/ (0xb7050000) => /lib/ (0xb6ffd000) => /lib/ (0xb6ec1000)
        /lib/ => /lib/ (0xb75eb000)
[oracle@abyssinian bin]$ ldd sqlplus => /export/oracle/product/8.1.7/lib/ (0xb7077000) => /export/oracle/product/8.1.7/lib/ (0xb7075000) => /lib/ (0xb7072000) => /lib/ (0xb7050000) => /lib/ (0xb6ffd000) => /lib/ (0xb6ec1000)
        /lib/ => /lib/ (0xb75eb000)
I checked all of those libraries, and the ones they include, and I never found it. Things that make you go hmm.....

Posted by Bruno Mattarollo on

I just did an "strace -fF -o strace.out svrmgrl" and then checked on the "strace.out" file and I can't see any reference (not even file not found) to libsk* ... Can you do an strace and see when it's loading (or trying to load it?) and where it's looking for it?


Posted by Janine Ohmer on
Thanks, Bruno, that got me a (small) step further. Strace shows that it's the oracle executable, trying to load, at the same spot where my Redhat 8 installation is trying to load instead.

Now ldd shows something interesting:

Redhat 8:

[oracle@ragamuffin bin]$ ldd oracle => /export/oracle/product/8.1.7/lib/ (0x40014000) => /export/oracle/product/8.1.7/lib/ (0x40398000) => /lib/ (0x403a1000) => /lib/ (0x403a4000) => /lib/ (0x403c6000) => /lib/ (0x403db000)
        /lib/ => /lib/ (0x40000000)
Redhat Enterprise:
[root@abyssinian bin]# ldd oracle => not found => not found => not found => /lib/ (0xb75dd000) => /lib/ (0xb75ba000) => /lib/ (0xb7568000) => /lib/ (0xb742c000)
        /lib/ => /lib/ (0xb75eb000) and are where they are supposed to be, so it must be the path to them that is wrong. And shouldn't be there; according to Metalink it does not exist on Linux for 8.1.7.

I also saw in the strace files that the Enterprise system keeps looking for libraries in the i686 directories, where the Redhat 8 one does not. So I'm guessing that there is a makefile out there getting confused about what OS it's being run on.

Hmm... very interesting indeed!

Posted by Janine Ohmer on
Ok, progress.... I redid the install with LD_ASSUME_KERNEL set to 2.4.7 and that allowed the Net 8 Assistant to run through properly. It also resulted in a better output from ldd:
[oracle@abyssinian bin]$ ldd oracle => not found => /export/oracle/product/8.1.7/lib/ (0xb725d000) => /export/oracle/product/8.1.7/lib/ (0xb7254000) => /lib/ (0xb7251000) => /lib/i686/ (0xb722e000) => /lib/i686/ (0xb71dd000) => /lib/i686/ (0xb70a4000)
        /lib/ => /lib/ (0xb75eb000)
I probably won't work on this much today (I do have other things i'm supposed to be doing) but I wanted to at least get this update posted. More will follow, as I do need to figure this out.
Posted by Bart Teeuwisse on

I don't have access to the machine on which I've setup Oracle 8.1.7 on RedHat Enterprise 3 so I can't give you the details. However, one tip I can give is to change in glibc-2.1.3-stubs.tar.gz so that you can see the errors being produced while rebuilding the client libraries.

Remove '>/dev/null' from line 73. Also remove '>/dev/null 2>&1' from lines 83 and 85.

This should give you an insight as to why there are '*0' backup files w/o relinked '*' files. Using the '*0' backup file is not going to solve your case as you are resorting to the file prior to patching thus negating the glibc-2.1.3 patch.

I'll post more when I have access to the RHE 3 machine.


Posted by Janine Ohmer on
HI Bart,

I did that (editing a few days ago and this is what I got:

I get this error when linking oracle

/usr/bin/ld: /export/oracle/product/8.1.7/rdbms/lib/oracle: hidden symbol `__fixunssfdi' in /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/libgcc.a(_fixunssfdi.oS) is referenced by DSO

This one when linking extproc, agtctl, hsalloci, hsots, hsdepxa

/usr/bin/ld: /export/oracle/product/8.1.7/rdbms/lib/extproc: hidden symbol `stat64' in /usr/lib/libc_nonshared.a(stat64.oS) is referenced by DSO

The ctype errors when linking oemagent, dbsnmp, oratclsh, tnslsnr, lsnrctl

then errors out without building anything because it tries to execute

rm -f /export/oracle/product/8.1.7/bin/

which of course doesn't work

Then these errors when linking ctxhx

/lib/ undefined reference to `__mailto:ctype_b_loc@GLIBC_2.3';
/lib/ undefined reference to `_dl_addr@GLIBC_PRIVATE'
/lib/ undefined reference to `_dl_open@GLIBC_PRIVATE'
/lib/ undefined reference to `_dl_close@GLIBC_PRIVATE'
/lib/ undefined reference to `_dl_sym@GLIBC_PRIVATE'
/lib/ undefined reference to `_dl_vsym@GLIBC_PRIVATE'

So some are ctype errors and some aren't.

I might be able to fix some of these by installing the compat packages, but that won't fix the ctype errors.

Clues, suggestions, etc?



Posted by madhu s on
you can get rid of some of the above errors

for  libgcc.a(_fixunssfdi.oS)
install gcc_old packages  the path will be /opt/gcc295  prepend this path to oracle path
and for ctxhx
the solution is to edit the file $ORACLE_HOME/ctx/lib/ and go to "INSO_LINK =", add a "$(LDLIBFLAG)dl" to the line and save it.

i have been  trying to install  8.1.7 on suse 9.0
got the same errors

except  rdbms/lib/extproc: hidden symbol `stat64' in /usr/lib/libc_nonshared.a(stat64.oS) is referenced by DSO
every thing is fine ( at least i was able to get through)

i tried to link them manully by  relink <individual component>
every thing went smoothly
if i say relink all  it is throwing  stat64.oS error

any idea/suggestion how to get through this error


Posted by Janine Ohmer on
I fiddled with this for days, and finally someone told me that you can take the compiled executables from a RH 8 system and just copy them over.  I tried it and it seemed to work just fine; I haven't put it into production yet but I didn't find anything that didn't work in my (brief) testing.

Anyway, I stopped trying to get the compile to work at that point.

Posted by Francisco Costa on
Hello everyone,

Someone could create a link to this file? I'm tired trying to solve this problem and I don't want to reinstall RH 8 just because of this...

Posted by Bart Teeuwisse on


I don't know which file you are refering to but you might find what you need to know in order to install Oracle 8.1.7 on RedHat 9 at

the Code Mill

Posted by Bart Teeuwisse on

I've written an article how to install Oracle 8.1.7 on RedHat Enterprise 3, available at

the Code Mill