Bug 19201 - Oracle 8.1.6.1.0 Enterprise Edition on RedHat 7.0.
Summary: Oracle 8.1.6.1.0 Enterprise Edition on RedHat 7.0.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.0
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Need Real Name
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-16 20:18 UTC by Need Real Name
Modified: 2016-11-24 14:55 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-04-22 01:09:16 UTC
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2000-10-16 20:18:50 UTC
bug report regarding Oracle 8.1.6.1.0 Enterprise Edition on RedHat 7.0.

Operating System	: RedHat 7.0
Oracle Version		: Oracle 8.1.6.1.0 Enterprise Edition
Hardware		: x86 (P-III 633, 128 Mb Ram, 8Gb IDE)

Updates Applied		: glibc-2.1.94-3.i386.rpm
			  glibc-devel-2.1.94-3.i386.rpm
			  glibc-profile-2.1.94-3.i386.rpm

Problem:
Unable to start the Oracle database server after installation
is complete.

Description:
The Oracle 8.1.6 installation goes through smoothly including copying of
files and the linking process.

However when the new database creation program starts up, the server
manager (svrmgrl) starts dumping core.

This is not a JDK problem, as I have made the Oracle installer write to a
shell script and then tried to execute the shell script from the command
prompt. We have the same problem.

Oracle support claims that there is a bug with the RedHat glibc in 7.0.

If it would help, we can send core files.

Comment 1 Perry Harrington 2000-12-07 09:24:56 UTC
using strace and ltrace can reveal a lot about where the program is dumping.

Comment 2 Allen Marshall 2001-01-18 19:28:21 UTC
See Bug 18391 which has similar problems.  Generally, the glibc version shipped with RH7 cannot be used by the Oracle 8.1.(5,6,7 ?) Universal Installer.


Comment 3 Need Real Name 2001-02-08 02:21:01 UTC
The "Fix" from the other bug report lets oracle works, but try getting anything else to run is a joke.  You can spend all day downloading Oracle 9i AS and 
it may compile alright, and you may be able to do the fix, but the actually forms and java processes seem to barf.

Is the *only* supported fix to go back to RedHat 6.2? That doesn't make sense from the business perspective since it isn't kernel 2.4 compatible and you 
know anyone running a database wants to make use of the journaling file systems, logical volume managers and the stable 2.4.1 raid kernel.  RedHat 6.2 
just doesn't offer that.

I'm personally trying to get Applications 11i (11.5.2) to install. I was able to get the database to load by hacking it to use the glibc compat to compile 
against, but the rapidwiz quickly failed afterwards when trying to run the tools cd install. 

Is there anything i can do to help solve this issue?  Redhat is redhat, and things should be forward compatible, especially when you buy RedHat 7.0 as a 
server, i can understand the workstation version having its quirks.

Is there anyway to update the libc's or work through this without hacking it up?

Comment 4 Ulrich Drepper 2003-04-22 01:09:16 UTC
Oracle code violates ABI rules left and right.  It can break at any time and
likely every time a major glibc change is added.  There is nothing left to do
but to pester Oracle to fix their code or use exactly the binary releasess they
were using in their QA.  For longer lifetimes you can use Red Hat Advanced
Server which has a certified Oracle version.  Otherwise you can only hope that
the next release won't hit yet another of Oracle's bugs.

For some of the problems (like object file portability) Oracle has some
workarounds but nothing will fully cure the problems unless they follow the ABI.

I will close the bug.  There is nothing we can do for the old code and there are
RHL versions after 7.0 which support Oracle.


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