"Error invoking target install of makefile /opt/oracle/product/9.0.1/plsql/lib/ins_plsql.mk" "Error invoking target install of makefile /opt/oracle/product/9.0.1/precomp/lib/ins-precomp.mk" "Error invoking target install of makefile /opt/oracle/product/9.0.1/precomp/lib/ins-net-client"
I saw this error only when I installed Oracle 9i (9.0.1). People have sent me emails pointing out that the following solution also works for Mandrake 8.1, Mandrake 8.2, and for SuSE 8.0.
Edit the file $ORACLE_HOME/bin/genclntsh and change the following line: LD_SELF_CONTAINED="-z defs" to read: LD_SELF_CONTAINED="" After that run the script $ORACLE_HOME/bin/genclntsh as the user "oracle" and not as the user "root". Also make sure you have all the Oracle environments set correctly! $ su - oracle $ $ORACLE_HOME/bin/genclntsh Created /opt/oracle/product/9.0.1/lib/libclntst9.a $ After that hit Retry in the error dialog window. This always worked for me.
Here is Oracle''''s official solution for Oracle 9iR1 and 9iR1 iAS on RedHat 2.1 Advanced Server: http://otn.oracle.com/software/products/oracle9i/files/binutils_readme.html
"Error in invoking target install of make file /opt/oracle/product/9.2.0/network/lib/ins_oemagent.mk"
I saw this error only on Red Hat 9. The ORACLE_HOME/install/make.log file contains the following error messages: ... /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-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.
Make sure to check all the digests and signatures contained in the downloaded RPMs since you never know if someone made changes to these RPMs or if someone replaced them. To ensure the integrity and origin of the RPMs, run the following commands: $ su - root # rpm --import /usr/share/rhn/RPM-GPG-KEY # 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 the RPMs 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.
If you have any problems or issues with this solution, or if you have any comments, please let me know. You can find my email address at the bottom of this web site.
$ dbca SIGSEGV 11* segmentation violation stackbase=0x453da000, stackpointer=0x453d9d5c Full thread dump: "AWT-EventQueue-0" (TID:0x411d1e20, sys_thread_t:0x453d9e0c, state:R) prio=5 *current thread* java.lang.Object.wait(Object.java) java.awt.EventQueue.getNextEvent(EventQueue.java:126) ... I got reports about dbca crashing on Red Hat 8.0 and on Red Hat 9. If this happens, try the following suggestion:
$ su - root touch /etc/rac_on Now try to restart dbca.
Another option is to edit $ORACLE_HOME/bin/dbca and to put the following lines under comment except the line marked in blue: # if [ -f /etc/rac_on ]; then # Run DBCA $JRE_DIR/bin/jre -native -DORACLE_HOME=$OH ... # else # Run DBCA # $JRE_DIR/bin/jre -DORACLE_HOME=$OH ... # fi
Now try to restart dbca.
./runInstaller: line 58: ./runInstaller: cannot execute binary file. You are probably trying to run a 64-bit Oracle version on a 32-bit Linux system. Make sure you downloaded the right Oracle version for your Linux system.
To check if runInstaller is a 32-bit binary or a 64-bit binary, run the following command: $ cd /mnt/cdrom $ file install/linux/runInstaller install/linux/runInstaller: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
To check if your Linux system is 32-bit system or a 64-bit sy
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
