Bug 18391 - Oracle 8.1.6 can't create database!
Oracle 8.1.6 can't create database!
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: 18880 19101 20866 22740 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-10-05 05:43 EDT by Need Real Name
Modified: 2008-05-01 11:37 EDT (History)
46 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-03 16:19:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Red Hat Bugzilla 2000-10-05 05:43:49 EDT
when create database use dbassist, process stop there do nothing.
Comment 1 Red Hat Bugzilla 2000-10-05 14:57:17 EDT
Oracle's dbassist is a Java application and Java seems to be broken for the
glibc coming with RHL7...?!
Comment 2 Red Hat Bugzilla 2000-10-05 22:14:32 EDT
It isn't entirely a JDK problem.
Oracle's installer uses it's own JRE to install the thing, and it's capable of 
going through the install fine where the various JDK's that fail to run fail 
Oracle's utilities all use the same JRE as it's installer uses (it is possible 
that some aspects of the dbassist utility may be triggering things that are 
broken with the JRE).
During the creation of the oracle database, you'll note that there are core 
dumps located in ORACLE_HOME/dbs directory.  This is where the Oracle server 
dumps core.  You'll find core_XXXXX directories located in there (or something 
to that effect).  This is the oracle server process dumping core.  It may be 
related to the Jserver aspect of oracle.  I'll be re-installing oracle without 
it's Jserver support this weekend to see if I can get the thing working.

The exact same thing happens when you attempt to start an Oracle database (and 
once again, my backup database includes Oracle's Jserver components so this may 
be the root of the cause).

Still this really should probably be a glibc bug and not an AnotherLevel bug 

Comment 3 Red Hat Bugzilla 2000-10-10 16:07:34 EDT
this problem was discussed on oracle's technet, too.
oracle thinks its a problem is an interaction with the new GNU Lib C shipped
with RH 7.
oracle sais they have communicated the problem to Red Hat.

any statement from redhat regarding this would be nice...
Comment 4 Red Hat Bugzilla 2000-10-11 06:41:18 EDT
Does it help if you install this week's glibc errata or not?
Comment 5 Red Hat Bugzilla 2000-10-11 06:42:20 EDT
*** Bug 18880 has been marked as a duplicate of this bug. ***
Comment 6 Red Hat Bugzilla 2000-10-11 07:01:20 EDT
yesterday i installed the new glibc package. (but not yet the new glibc-devel
that did not change the situation
Comment 7 Red Hat Bugzilla 2000-10-11 15:20:29 EDT
Ok, one more thing about Oracle.  Just "debugged" another problem here.

Starting from glibc > 2.1.91, _running_ oracle database (installed
with 2.1.3) behavos incorrectly here.  When I connects to it using any
tool (e.g. sqlplus) and issue some queries, all looks just fine.  But
if I "sleep" some time (about ~10 mins) and issue just the same query
again, it will lock up for about 1..3minutes and only after this will
respond with results.  Interestingly that if I issue another query (or
just login/logout) at a time of lockup, both clients will continue
(this was a "workaround" -- if your query stalled, just "ping" a db
using sqlplus).  _All_ glibc versions starting from 2.1.92 shows
this nicely here.  And both 7.0 and errata's 2.1.94 shows it.

For now, I have a workaround here: I placed all the glibc-2.1.91-19
files from /lib to /usr/oracle/lib (oracle hardcodes /usr/oracle/lib
to ld_run_path), so that oracle's processes uses this exact version
(it works just fine), while other processes uses never version from
/lib.  It is ugly.  But definitely something was broken between
2.1.91 and 2.1.92 "releases".  I tried to debug this using strace,
but for no avail now -- oracle issues so many _ugly_ syscalls (yes,
it is _very_ ugly in this respect -- the way it works) that I was
unable to determine what's happenes...

BTW, Should this be a new bug? :)
Comment 8 Red Hat Bugzilla 2000-10-11 17:09:20 EDT
Ok, some new info.  My problem is not solved by using 2.1.91 -- it just
takes longer time to start appearing again; and on another machine
that uses exactly the same kernel (2.2.16-3) and glibc (2.1.91-18)
things works well.  I need further investigations here.

But some issues related to the original problem.

$ORACLE_HOME/bin/oracle executable won't start (it segfault on
startup/init) when linked by current 7.0 gcc with any version of
glibc >= 2.1.91 (and using 7.0 binutils -- compiler may be irrelevant
here).  Executable linked by previous gcc with previous
glibc works (with some glitches but them can be unique for me).
Remember -- when oracle installs it relinks all the executables!
I'd suggest to extract original `oracle' executable (available
in oracle installation media somewhere at stage/Components/...rdbms...
inside .jre (.zip) archive) and see if _that_ executable works.
Comment 9 Red Hat Bugzilla 2000-10-13 20:27:30 EDT
I recompiled glibc 2.1.3 from RedHat 6.2 using gcc 2.96 under 7.0.
If I replace sprintf.os and vfprintf.os compiled with gcc 2.96 under
7.0, the resuling libc-2.1.3.so won't work right with oracle under
RedHat 6.2. So there are differences in sprintf.os and vfprintf.os
between compiled with egcs in 6.2 and gcc 2.96 in 7.0. I am not sure
if the same files are affected in glibc 2.1.94.
Comment 10 Red Hat Bugzilla 2000-10-16 04:36:37 EDT
The main problem Oracle has and has been informed about is the relinking
on the target. That's a big no-no, glibc has never guaranteed binary
compatibility with object files compiled with different glibc headers
(as opposed to maintaining binary compatibility with shared libraries and
binary programs). This can break between any minor glibc releases, not just
2.1.3->2.2, e.g. 2.1.2->2.1.3 could have beaten them as well.
So for now, you should install Oracle on 6.2 (or hack their install scripts
so that the scripts use i386-glibc21-gcc as compiler to link stuff together
and -L/usr/i386-glibc21-linux/lib somewhere in LDFLAGS).
To H.J.: can you find out what arguments given to *printf behave differently?
Comment 11 Red Hat Bugzilla 2000-10-16 16:52:41 EDT
Just as an FYI. This has been reproduced in our test lab using 7.0 with the
latest glibc update. All goes well until database creation where it hangs at
Initializing Database 80%. Looking around shows the binary 'svrmgrl' taking up
99.9% CPU and 2.5 MB of memory using top.
Comment 12 Red Hat Bugzilla 2000-10-16 17:27:48 EDT
From my experience, it is better to build database by hand, not using
the installer/dbassist.  Use
to rebuild oracle client shared lib,
  make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk install
to relink/install oracle executable,
  make -f $ORACLE_HOME/svrmgr/lib/ins_svrmgr.mk install
to install/relink svrmgr, and then run script generated by dbassist
(placed somewhere in $ORACLE_HOME, probably in install/ directory).
This way you can see what's happened and what statement(s)

BTW, 80% is probably the place where database internal java machine
should be initialized (not to confuse with external java machine,
this one is all inside oracle and does not uses any external support
files except of those provided by oracle itself (again, not counting
jdk as "external" for oracle product) and by the c libraries).
Look to the logs, them should be available somewhere (this is why
I prefer to install things myself -- there is a trouble finding
those logs and to figuring out where error occured, as the dbassist
logs contains _tons_ of debugging info from dbassist itself).
Comment 13 Red Hat Bugzilla 2000-10-16 17:30:36 EDT
BTW, dkl@redhat.com, this was a step further.  "Normally" oracle
executable won't start, so dbassist should stop near 0%.  At your
case, 80% was done.
Comment 14 Red Hat Bugzilla 2000-10-16 19:40:56 EDT
Plsase get


for instructions. Let me know if it works for you or not.

BTW, glibc 2.1.94-3 is required.
Comment 15 Red Hat Bugzilla 2000-10-17 13:35:00 EDT
H.J.L, can you please tell what exactly modules/objects caused the problems
(already mentioned *printf)?  Is that in startup modules like crt*.o, or
in libc?  If it is the latter, then it is simpler/better to just add little
library with expected by oracle interfaces (only including those objects)
and place it to e.g. $ORACLE_HOME/lib (and add corresponding -l option)
instead of making all that great changes.  This will _not_ cure installation
process (as one can't just easy edit makefiles while oracle installs),
but it is ok for "after-install" stage -- just trivial script that patches
makefiles and calls `make -f ... install'; after that one can use dbassist
or something to actually create database.  But yes, if is't in the crt*,
than this will not work.  (Huh, probably will, by playing with -B option
for gcc).
Comment 16 Red Hat Bugzilla 2000-10-17 14:11:48 EDT
gcc 2.96 is fine and glibc 2.1.94-3 is fine. The problem is shmctl ():

# objdump --dynamic-sym /lib/libc.so.6 | grep shmctl
000e22d4 g    DF .text  00000219  GLIBC_2.2   shmctl
000e24f0 g    DF .text  00000051 (GLIBC_2.0)  shmctl

Oracle 8i is compiled against glibc 2.1.3. During the Oracle install,
they link/compile binaries from .o and .a files. Glibc 2.1.3 has to be
used for the Oracle install. shmctl is just one of those functios which
have a newer version in glibc 2.2. That is why my glibc 2.1 SDK is needed.

BTW, compat-glibc and kgcc are only available under RedHat. And they
are not quite right as a glibc 2.1 SDK. My glibc 2.1 SDK should
work on all glibc 2.2 based systems.
Comment 17 Red Hat Bugzilla 2000-10-17 15:27:41 EDT
Can the others also affect this?  I see also the same changes with
(only "interesting" ones are listed): msgctl, semctl (oracle uses semaphores),
getrlimit, fsetpos/fgetpos (!).

btw, what about just adding some sort of ld script (instead of providing
additional lib or the whole sdk) that defines versions of that routines
explicitly (like "GLIBC_2.0 { shmctl; ... }") in $ORACLE_HOME/lib/libc.so
(that should also point to /lib/libc-... and others like /usr/lib/libc.so
does)?  (I'm not a guru here, just looked to `info ld' here -- this
just to show an "idea", details maybe different).
Or, another case, add a lib (also can be done via $OH/lib/libc.so)
with contents like
  __asm__(".symver shmctl,shmctl@GLIBC_2.0");
(compiled ofcouse!)

I still didn't tried the sdk (it seemed to be that our provider have
PMTU discovery problem, so it's hard to download large files for me
now).  Does anybody knows if this sdk cures the problem?  I saw that
oracle dies at shmctl call, so probably you're right here;  but
sprintf also was mentioned here -- what's with _this_ routine?
Comment 18 Red Hat Bugzilla 2000-10-17 15:33:07 EDT
I got 2 confirmed success reports with my SDK.
Comment 19 Red Hat Bugzilla 2000-10-17 16:21:21 EDT
The valinux fix did not work for me.  I did a fresh RH7 install, 
made the valinux changes (steps 1, 2, 3: README.Oracle8i), installed 
Oracle and did the valinux post install (undo the valinux changes with 
steps 5, 6, 7: README.Oracle8i).  I did not try to create the database 
by the shell scripts saved from dbassit since I wanted to adjust the 
listerner parameters first.  lsnctrl stop|start just segs faults.  
Without the listerner, I do not consider this a workable fix.

If I have installed and created databases under RH6.2, will upgrading 
to RH7 (by the RH7 installer upgrade option) still make Oracle unusable?
Comment 20 Red Hat Bugzilla 2000-10-17 16:53:21 EDT
I can reproduce the problem. It is because somehow glibc 2.2 is used to
relink lsnctrl. I will work with Oracle to fix it.
Comment 21 Red Hat Bugzilla 2000-10-17 17:20:37 EDT
Oracle has been already told by Ulrich Drepper and myself that they
there is no binary compatibility for .o/.a files assured even
between glibc minor releases.
H.J., what's the problem with compat-egcs and compat-glibc that
it cannot be used for Oracle installation?
Comment 22 Red Hat Bugzilla 2000-10-17 17:29:18 EDT
You cannot use /usr/lib nor /usr/include for any glibc 2.1 compile/link.
My glibc 2.1 SDK won't go outside of /usr/i386-glibc-2.1-linux for anything.
It even comes with its own ld, which won't even look at /lib nor /usr/lib.
Comment 24 Red Hat Bugzilla 2000-10-18 00:02:35 EDT
The latest valinux fix seems to work (listener, dbassst).  I do not have 
a comprehensive test suite for full varification but things look fine so 


p.s. On the valinux ftp site there are multiple glibc 
(i386-glibc-2.1-linux-20001016.tar.gz and i386-glibc-2.1-linux-20001017.tar.gz).
What is the difference between them? Does one have a debug symbols and the 
other does not?
Comment 25 Red Hat Bugzilla 2000-10-18 02:12:14 EDT
i386-glibc-2.1-linux-20001016.tar.gz is removed now. You can forget about even
existed :-).
Comment 26 Red Hat Bugzilla 2000-10-20 10:01:58 EDT
*** Bug 19101 has been marked as a duplicate of this bug. ***
Comment 27 Red Hat Bugzilla 2000-10-23 22:22:19 EDT
Looks like nearly the identical problem has occurred before:

Comment 28 Red Hat Bugzilla 2000-10-25 18:19:17 EDT

Does anyone have the final fix for this?? I cannot get the above to work. If I move the lib's to a saved folder as someone above suggests, then nothing will 
work, ie ls, su, and the oracle installer cannot even start without these libraries. If I explcitly point my LD_LIBRARY_PATH to the glib2.1 directory 
everything seg faults. I followed the above fix exactly with the exception of moving the libraries which did not work.

Can anyone point me in the right direction.

I have the updated glibc, as well as the other one I downloaded from valinux.

Thanks greatly,
Comment 29 Red Hat Bugzilla 2000-10-30 01:18:48 EST
Unfortunately the SDK doesn't really solve the real problem. 
Nor does the fault of this problem Oracle's, though they've 
certainly exercerbated the consequences.

The fact is that the binaries Oracle ships with are only part of the
system. It also includes the client libraries. From what you've described
there is absolutely no way to ship a portable library that can be used even
on multiple minor versions of glibc. To comply with your policies Oracle would
have to ship a separate set of .o files for each minor release of glibc. And any
subsequent release would risk making it impossible to compile clients.

That's frankly ludicrous.
Comment 30 Red Hat Bugzilla 2000-10-30 01:28:25 EST
That's how symbol versioning works and has worked ever since it
appeared. If you want to ship a library portable accross many
glibc major/minor versions, simply ship it as a shared library and
it will work. Symbol versioning is a matter of final link.
Comment 31 Red Hat Bugzilla 2000-11-03 16:10:59 EST
jakub@redhat.com , we have RH7 and Oracle 8i. We applied the fixes as specified 
by hjl@valinux . the database has crashed twice in the last 24 hrs. I was 
wondering if this was a long-term fix, or is there some patches from red-
hat/valinux, that has been released already or in the pipeline. I did see some 
new 'respin' files in the ftp directory, will they have any useful updates that 
will help in this oracle problem. thank you. (hjl@valinux included)
Comment 32 Red Hat Bugzilla 2000-11-05 15:36:01 EST
I finally relinked oracle exes on 7.0 without big valinux "collection".
Here is how I did this, in case this can be useful to someone.

I got glibc-2.1.3-xxx.rpm from redhat mirror (from 6.something, does not
matter). I extracted and put the following files to $ORACLE_HOME/lib:


  (those was symlinks to some like libXX-2.1.3.so, I copied targets).

After this, I created file $ORACLE_HOME/lib/libc.so with one line:

--- cut ---
  GROUP ( /usr/oracle/lib/libc.so.6 /usr/oracle/lib/ld-linux.so.2
/usr/lib/libc_nonshared.a )
--- cut ---
(ld-linux needed here to satisfy reference to _dl_init_next@GLIBC2.0 from
libc.so.6).  My $ORACLE_HOME was in /usr/oracle, as you can see.

Ok, this is a "development environment".
I relinked all oracle exes with this "setup".  From this point, all goes
ok (works for me (tm)).

Even one thing that I not tried (and will not try) may be considered
is to do that steps before installing oracle: create ORACLE_HOME/lib
and place all those files there, and _after_ just install oracle as
usual.  This probably should work.

BTW, I have no java components here (moreover, I removed all references
to java (aka java "option") from oracle libs (hack, hack!)), so I not
checked if this will work with java.  But why not? :)

BTW2, all other tools used from rh7.0 including gcc/binutils etc etc,
even math library was from glibc2.2 (as you can notice).

That's all...  Please correct me if I'm wrong here.
Comment 33 Red Hat Bugzilla 2000-11-05 15:49:48 EST
Oops, one little correction:
   GROUP ( /usr/oracle/lib/libc.so.6 ...
should be  /usr/oracle/lib/libc-2.1.3.so
instead...  Just my typo.

BTW, the names I choosed for all those .so's will allow both
build with glibc-2.1.3 and run with system's 2.2, since for libXXX.so
used for build, but libXXX.so-N used for run.
Comment 34 Red Hat Bugzilla 2000-11-07 16:58:09 EST
Hello All,
Just to let you know. I created a tar/gzip image of entire Oracle
directory from a RedHat 6.2 Oracle 8.1.6 installation and copied
it over to my RedHat 7.0 installation and unzaipped the contents
into exactly the same directory path as on RedHat 6.2.
After setting the ORACLE_HOME and ORACLE_SID exactly same as on the
RedHat 6.2 system and copying the /etc/ora* files, I was able to
startup my Oracle 8.1.6 database on the RedHat 7.0 without problems.
Initial tests show that it works and I can connect to the database.
More extensive tests may be needed to establish the stability of
this installation.
If you can, try getting a gzip image of the oracle installation from
a RedHat 6.2 system. This might be one of the solutions for those
who can manage to get such a installation image.
Comment 35 Red Hat Bugzilla 2000-11-15 04:44:55 EST
*** Bug 20866 has been marked as a duplicate of this bug. ***
Comment 36 Red Hat Bugzilla 2000-11-15 12:54:30 EST
I have a problem with the installation of JServer of Oracle 8.1.6 EE R2 on Red 
Hat 6.2. Every time I try to install it, I get "end-of-line on commuincation 
channel" and "VM: Killing oracle process" ... Also, I've another problem when I 
use dbassist the modify an existing database, dbassist crashes ...

Do these problem relate the the problem of glibc?

Any help will be apprecaited very much. I tried the discussion forums in 
otn.oracle.com. But, it did not get helpful answers ... I hope I get it here
Comment 37 Red Hat Bugzilla 2000-11-16 12:57:51 EST

I ran the following script to change all references to cc and gcc 
to /usr/bin/i386-glibc21-gcc, and changed the genclntsh script so that LD uses 
a different link script, searching for /usr/i386-glibc21-linux/lib first. After 
that, I could create and connect to the database, and had no problems with 
listener. This idea is based on what the patch supplied for Oracle 8.0.5 does.


LIST=`rgrep -rl -x mk "gcc" .`
for FILE in $LIST ; do
	# Make a backup
	if [ ! -f $NAME.orig ]; then
		cp $NAME $NAME.orig
	# Change cc and gcc for /usr/bin/i386-glibc21-gcc
	sed -e "s/gcc/\/usr\/bin\/i386-glibc21-linux-gcc/
s/CC=cc/CC=\/usr\/bin\/i386-glibc21-linux-gcc/" $NAME > $NAME.new
	mv $NAME.new $NAME
Comment 38 Red Hat Bugzilla 2000-11-17 14:16:04 EST
Doc ID:  Note:121176.1 
Subject: doesn't start on RedHat Linux 7.0 after relinking 
Type:  ALERT 
Status:  REVIEWED 
 Content Type:  TEXT/PLAIN 
Creation Date:  03-OCT-2000 
Last Revision Date:  24-OCT-2000 
Language:  USAENG 

This article is being delivered in Draft form before publishing standards have 
been applied, and may contain errors. Please use the MetaLink  "Feedback" 
button to advise Oracle of any issues related to this article or this process. 

Oracle does not start on RedHat Linux 7.0 after relinking

Versions Affected 
  Product & Oracle versions affected Enterprise Edition for Linux
Platforms Affected 
  RedHat Linux 7.0 and probably any glibc-2.1.9x based distribution.
  After upgrading from earlier versions of RedHat Linux to RedHat 7.0
   Oracle fails to start up after being relinked. The reason is a
   generic incompatibility across different major versions of GNU libc
   that does not guarantee that a binary linked against a version of
   glibc will keep working if relinked in an environment of a later
   major glibc release. Since Oracle is linked against
   glibc-2.1.3 and RedHat 7.0 ships with glibc-2.1.9x, we experience
   the described problem.

Likelihood of Occurrence 
  This problem will occur after relinking Oracle to install patches or
   kernel options or to deinstall them. It will NOT occur if Oracle is
   not relinked after the OS upgrade.

Possible Symptoms 
  Starting up the database fails with ORA-3113 after some time spent
   looping in semop() and a core file is generated. The stack trace
   taken with GDB is the following:

(gdb) where
#0  0x404c74e1 in __kill () from /lib/libc.so.6
#1  0x8469156 in slcra ()
#2  0x846cd01 in ssexhd ()
#3  0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, 
      __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 3221208616, 
      esi = 3221208744, ebp = 3221208516, esp = 3221207644, ebx = 3221207676, 
      edx = 0, ecx = 3221207676, eax = 0, trapno = 14, err = 4, 
      eip = 138857746, cs = 35, __csh = 0, eflags = 2163270, 
      esp_at_signal = 3221207644, ss = 43, __ssh = 0, fpstate = 0x0, 
      oldmask = 0, cr2 = 8}) at signals.c:97
#4  <signal handler called>
#5  0x846cd12 in ssexhd ()
#6  0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, 
      __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 3221209840, 
      esi = 3221209968, ebp = 3221209740, esp = 3221208868, ebx = 3221208900, 
      edx = 0, ecx = 3221208900, eax = 0, trapno = 14, err = 4, 
      eip = 138857746, cs = 35,__csh = 0, eflags = 2163351, 
      esp_at_signal = 3221208868, ss = 43, __ssh = 0, fpstate = 0x0, 
      oldmask = 0, cr2 = 8}) at signals.c:97
#7  <signal handler called>
#8  0x846cd12 in ssexhd ()
#9  0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, 
      __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 3221211064, 
      esi = 3221211192, ebp = 3221210964, esp = 3221210092, ebx = 3221210124, 
      edx = 0, ecx = 3221210124, eax = 0, trapno = 14, err = 4, 
      eip = 138857746, cs = 35, __csh = 0, eflags = 2163347, 
      esp_at_signal = 3221210092, ss = 43, __ssh = 0, fpstate = 0x0, 
      oldmask = 0, cr2 = 8}) at signals.c:97
#10 <signal handler called>
#11 0x846cd12 in ssexhd ()
#12 0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, 
      __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 153736192, 
      esi = 3221213276, ebp = 3221211380, esp = 3221211320, ebx = 3575600, 
      edx = 3221211332, ecx = 1745, eax = 502, trapno = 14, err = 6, 
      eip = 145158780, cs = 35, __csh = 0, eflags = 2163219, 
      esp_at_signal = 3221211320, ss = 43, __ssh = 0, fpstate = 0x0, 
      oldmask = 2147483648, cr2 = 1745}) at signals.c:97
#13 <signal handler called>
#14 0x8a6f27c in sskgmstat ()

  (for RedHat 7.0) Install the following packages:


   and modify all occurrences of CC and LINK definitions in all env_*.mk
   makefiles in the $ORACLE_HOME software tree from either $(LDCCOM) or
   gcc to i386-glibc21-linux-gcc.

  To better illustrate the needed changes, the lines such as


   will become

    LINK=$(PURECMDS) i386-glibc21-linux-gcc $(LDFLAGS) $(COMPOBJS)

  You will also need to modify the genclntsh shell script and substitute

    LD="ld -shared  -L${ORACLE_HOME}/lib"
    LD_OPT="-h ${CLNT_LIB}"


    LD="i386-glibc21-linux-gcc -shared  -L${ORACLE_HOME}/lib"

  Finally, rebuild libclntsh.so by running 'genclntsh' and relink oracle,
   svrmgrl etc. using the usual relink commands. You'll get warnings in
   the relink process but they can be ignored.

  This has been tested on env_rdbms.mk, env_sqlplus.mk, env_network.mk
   but should be working on the other makefiles as well.

  Other possible workarounds:

   - downgrade to RedHat 6.2
   - get a copy of the oracle kernel and utilities such as svrmgrl, imp,
      exp etc. from a RedHat 6.2 box and place them in $ORACLE_HOME/bin
   - if you haven't relinked multiple times, it's enough to copy back the
      old binary versions in $ORACLE_HOME/bin (such as oracleO, impO etc.)
      to oracle, imp etc.

   Note that the two latter workarounds will not allow you to relink the
    Oracle kernel and/or utilities - the resulting binaries will not run
    under a glibc-2.1.9x system.


                                                      Oracle Support Services

Comment 39 Red Hat Bugzilla 2000-11-17 16:25:04 EST
I would love to try the downgrade to RH6.2 workaround.  However, I would need 
to get a *supported* version of RH6.2 (since I just purchased RH 7.0 and wasn't 
doing an upgrade).  How can I get a copy to implement the workaround 
(downloading for 27 hours isn't my idea to a great way to get a copy and any 
download I have found is for *unsupported* RH 6.2).

Do I have any options?
Comment 40 Red Hat Bugzilla 2000-12-09 01:15:41 EST
I have tried the above fix for Red hat 7.0 and get the following errors when 
running genclntsh.

i386-glibc21-linux-gcc: /usr/oracle/product/8.1.7/lib/clntsh.map: No such file 
or directory
i386-glibc21-linux-gcc: libclntsh.so.8.0: No such file or directory
genclntst: error: could not locate /usr/oracle/product/8.1.7/lib/clntsh.map
           please generate the client shared library first

I am using the following egcs version
package compat-egcs-c++-6.2- is already installed
package compat-glibc-6.2- is already installed

Comment 41 Red Hat Bugzilla 2000-12-22 09:37:56 EST
*** Bug 22740 has been marked as a duplicate of this bug. ***
Comment 42 Red Hat Bugzilla 2001-01-18 04:28:57 EST
To avoid that error make sure the map option is passed correctly. I used:

   LD_OPT="-Wl,-Map=${MAPFILE} -Wl,-h${CLNT_LIB}"
Comment 43 Red Hat Bugzilla 2001-01-18 15:34:15 EST
I performed the above-mentioned Valinux fix successfully. I cannot say with any certainty that ORacle is stable for production, however. I use it only for 
light duty development purposes right now. There were some gotchas though: 

1) After the failed install, and performing the steps recommended in the Valinux posting at the bug entry, I was only able to get through the installation 
successfully by 'upgrading' RH7. Even though my workstation
was a new install, the process of trying to get Oracle on, putting on GLIB patches, performing the Valinux fix, etc. lef the system confused. A phony 
upgrade restored its pristine state. Simply run install off the CD
or source area, and select upgrade instead of install. It fixes all that was wrong. Reboot. 

2)I then ruthlessly whacked all the Oracle install stuff except for the empty ORACLE_BASE and ORACLE_HOME directory trees. I left my oracle user 
and group configurations alone. I did double check
directory permissions. 

3) Then, I redid the Valinux fix on the 'pristine' system. 

4) Install then concluded fine. 

5) DBASSIST still misbehaved creating my 2nd instance after install. I opted for it to make a script instead of trying to auto-build the instance. The script 
ran fine. 

6) I was perturbed to note that several Oracle scripts misbehaved, particularly /etc/init.d/dbora as well as $ORACLE_HOME/bin/dbstart and 
$ORACLE_HOME/bin/dbstop. I was unable to get dbora to spawn
dbstart or dbstop in the background during init or shutdown. I gave up and let them run foreground. Probably my problem. Also, dbstart had to be hacked 
to look for the right product signature. It looks for this to
figure out what version of Oracle it is trying to start up. As installed, it expected 'PL/SQL' to come back but that string never appears during ORacle 
startup for me. I changed it to look for 'Oracle8i Enterprise'
and all was well then with dbstart. YMMV. Any guidance on this is welcome. 

7) DBASSIST seems to puke silently if it can't find the target instance build directory it wants, for example, u03/oradata/... That was vaguely annoying. 


Allen Marshall
Comment 44 Red Hat Bugzilla 2001-02-19 20:15:32 EST
This bug has been around since 2000-10-05.  Red Hat's inability to provide a 
solution by now indicates a lack of commitment to the database community.  
Oracle is a core enterprise-level product that should have been thoroughly 
tested before RH7.0 was shipped.
Comment 45 Red Hat Bugzilla 2001-05-03 14:18:25 EDT
Has this bug been fixed in Red Hat 7.1, or shall I invest in a competing
Comment 46 Red Hat Bugzilla 2001-05-03 16:19:05 EDT
	Whilst I agree that the non-attempt to resolve this problem is a disgrace and
dissapointing. Check out technet.oracle.com for the latest version of Oracle 8i.
There are additional glib stubs. Although I haven't tried it myself it sounds
like it should resolve the problem.

Comment 47 Red Hat Bugzilla 2001-05-04 05:23:59 EDT
We cannot fix this bug, since the bug is in Oracle.
But we have provided a workaround for this, see 7.1 RELEASE-NOTES.

Note You need to log in before you can comment on or make changes to this bug.