Forum OpenACS Q&A: Installing Oracle 8.1.7 on Red Hat 9
I'm trying to install Oracle 8i on Red Hat 9. I've installed the following compat libs:
compat-libstdc++-devel-7.3-2.96.118 compat-gcc-c++-7.3-2.96.118 compat-libstdc++-7.3-2.96.118 compat-gcc-7.3-2.96.118 compat-libgcj-7.3-2.96.118 compat-db-3.3.11-4 compat-libgcj-devel-7.3-2.96.118
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 setup_stubs.sh 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 ins_net_server.mk 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?
I started up the install, with LD_ASSUME_KERNEL set to 2.2.5 as always. The install stopped with an error linking in ins_precomp.mk. At that point I installed the glibc patch, and that let me continue for a bit. But now I'm stuck on ins_oemagent.mk, 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?
One note: I haven't installed compat-glibc-6.2-126.96.36.199.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.
... /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.9then 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.
I installed Oracle 8.1.7 (and then the patch 188.8.131.52) 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:
before running the installer.# cd /usr/bin # mv gcc gcc32 # ln -s gcc296 gcc
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
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....
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:
- make sure LD_ASSUME_KERNEL is set to 2.2.5
- run through the 184.108.40.206 install, choosing ignore for all errors
- at the second root.sh prompt, run root.sh and then apply the glibc patch
- the Net8 Assistant never comes up, which hangs the install, so kill it at this point
- 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)
- install 220.127.116.11 patch, choosing ignore for all errors
- apply the glibc patch again
- run a script to cp and chmod files that are missing or have permissions set wrong (see below)
- run dbassist and save files to disk
- manually run the first file dbassist creates
error while loading shared libraries: libskgxp8.so: 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
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.
[oracle@abyssinian bin]$ svrmgrl Oracle Server Manager Release 18.104.22.168.0 - Production Copyright (c) 1997, 1999, Oracle Corporation. All Rights Reserved. oraclemuffin: error while loading shared libraries: libskgxp8.so: cannot open shared object file: No such file or directory oraclemuffin: error while loading shared libraries: libskgxp8.so: cannot open shared object file: No such file or directory ORA-12547: TNS:lost contactThe 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 22.214.171.124.0 - 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 directorySo 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.
Neither of them are linking it in directly:
[oracle@abyssinian bin]$ ldd svrmgrl libwtc8.so => /export/oracle/product/8.1.7/lib/libwtc8.so (0xb75e8000) libclntsh.so.8.0 => /export/oracle/product/8.1.7/lib/libclntsh.so.8.0 (0xb7075000) libdl.so.2 => /lib/libdl.so.2 (0xb7072000) libm.so.6 => /lib/libm.so.6 (0xb7050000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6ffd000) libc.so.6 => /lib/libc.so.6 (0xb6ec1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000) [oracle@abyssinian bin]$ ldd sqlplus libclntsh.so.8.0 => /export/oracle/product/8.1.7/lib/libclntsh.so.8.0 (0xb7077000) libwtc8.so => /export/oracle/product/8.1.7/lib/libwtc8.so (0xb7075000) libdl.so.2 => /lib/libdl.so.2 (0xb7072000) libm.so.6 => /lib/libm.so.6 (0xb7050000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6ffd000) libc.so.6 => /lib/libc.so.6 (0xb6ec1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)I checked all of those libraries, and the ones they include, and I never found it. Things that make you go hmm.....
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?
Now ldd shows something interesting:
[oracle@ragamuffin bin]$ ldd oracle libjox8.so => /export/oracle/product/8.1.7/lib/libjox8.so (0x40014000) libobk.so => /export/oracle/product/8.1.7/lib/libobk.so (0x40398000) libdl.so.2 => /lib/libdl.so.2 (0x403a1000) libm.so.6 => /lib/libm.so.6 (0x403a4000) libpthread.so.0 => /lib/libpthread.so.0 (0x403c6000) libc.so.6 => /lib/libc.so.6 (0x403db000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)Redhat Enterprise:
[root@abyssinian bin]# ldd oracle libskgxp8.so => not found libjox8.so => not found libobk.so => not found libdl.so.2 => /lib/libdl.so.2 (0xb75dd000) libm.so.6 => /lib/libm.so.6 (0xb75ba000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7568000) libc.so.6 => /lib/libc.so.6 (0xb742c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)libjox8.so and libobk.so are where they are supposed to be, so it must be the path to them that is wrong. And libskgxp8.so 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!
[oracle@abyssinian bin]$ ldd oracle libskgxp8.so => not found libjox8.so => /export/oracle/product/8.1.7/lib/libjox8.so (0xb725d000) libobk.so => /export/oracle/product/8.1.7/lib/libobk.so (0xb7254000) libdl.so.2 => /lib/libdl.so.2 (0xb7251000) libm.so.6 => /lib/i686/libm.so.6 (0xb722e000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb71dd000) libc.so.6 => /lib/i686/libc.so.6 (0xb70a4000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (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.
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 setup_stubs.sh 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.
I did that (editing setup_stubs.sh) 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 ins_precomp.mk 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/libdl.so.2: undefined reference to `__ctype_b_loc@GLIBC_2.3';
/lib/libdl.so.2: undefined reference to `_dl_addr@GLIBC_PRIVATE'
/lib/libdl.so.2: undefined reference to `_dl_open@GLIBC_PRIVATE'
/lib/libdl.so.2: undefined reference to `_dl_close@GLIBC_PRIVATE'
/lib/libdl.so.2: undefined reference to `_dl_sym@GLIBC_PRIVATE'
/lib/libdl.so.2: 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?
you can get rid of some of the above errors
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/env_ctx.mk 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
Anyway, I stopped trying to get the compile to work at that point.
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...