People referred a problem with glibc
lanching oraInstaller:
Unable to load native library:
/tmp/OraInstall2004-02-24_10-40-59AM/jre/lib/i386/libjava.so: symbol
__libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link
time reference. In this case you need to install patch #3006854 from
metalink which create a new library containing the definition for
__libc_wait.
Maybe setting LD_ASSUME_KERNEL='2.4.20' helped: I didn't need to apply
the patch in either installation: 9i and 10g.
If you can't access metalink then you can create your own patch as
suggested by Jakub Jelinek (I found the trick on suse-oracle mailing
list):
------- From Jakub Jelinek on 2003-11-21 16:49 -------
Try using some less buggy JVM.
Latest Sun JDK should work just fine for example.
Or, as a workaround for the buggy JVM, you can try:
gcc -O2 -shared -o ~/libcwait.so -fpic -xc - <<\EOF
#include <errno.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/wait.h>
pid_t
__libc_wait (int *status)
{
int res;
asm volatile ("pushl %%ebx\n\t"
"movl %2, %%ebx\n\t"
"movl %1, %%eax\n\t"
"int $0x80\n\t"
"popl %%ebx"
: "=a" (res)
: "i" (__NR_wait4), "0" (WAIT_ANY), "c" (status), "d" (0),
"S" (0));
return res;
}
EOF
--------------------------------------------------------
export LD_PRELOAD=~/libcwait.so
now you can install.
Rainer Kaluscha (rainer.kaluscha _at_ uni-ulm.de) reported and solved three issue met on this same architecture.
With his consent I'm pasting the piece of mail covering them. Thank you Rainer!
I encountered 3 problems not mentioned there. The solutions
may be interesting for others so you might want to include them in
your howto:
1. The database assistant refused to create a database with charset
WE8ISO8859P15 - only WE8ISO8859P1 works ...
2. ulimit: the user oracle had a limit on file size - so I ran into
trouble when a datafile grew beyond 4GB ...
ulimit -f unlimited cured this (alternatively, one could probably
also use osh)
3. The third one was trickier: I'm using the Intermedia text option.
The INSO filtering utility ctxhx couldn't be linked because only a
32bit version of ctxhx.o is present, the libraries are in
$(OH)/ctx/lib32 and the makefile ins_ctx.mk is ignorant on that.
As ctxhx only works as a filter for temporary files I tried an
executable from a 32bit machine. However, that one also had a (known)
bug (undefined symbol: stat). By creating a dummy stat.c (cmp.
http://www.lyranthe.org/diary/archives/2002/02/ctxhx_with_linu.html)
like this:
/*
workaround for bug: undefined symbol: stat
provides a function stat instead of inlined code
*/
#include <sys/stat.h>
/* extern __inline__ */ int stat (__const char *__path,
struct stat *__statbuf) __THROW
{
return __xstat (_STAT_VER, __path, __statbuf);
}
and including it into ins_ctx.mk *before* the INSO libs:
ctxhx: $(CTXHXOBJ) $(ORACLE_HOME)/ctx/lib/stat.o
$(LINK) $(CTXHXOBJ) $(ORACLE_HOME)/ctx/lib/stat.o $(INSO_LINK)
I was able to link and run ctxhx on the 32bit machine.
Copying the executable to the 64bit machine and including the 32bit
libraries in LD_LIBRARY_PATH did the trick. You might have to set an
s-bit on ctxhx as it runs with the current user id while Oracle
create the temporary files with owner/group oracle:dba ...