Bug 19101 - Oracle 8.1.6 Release 2 will not run on Redhat 7.0
Oracle 8.1.6 Release 2 will not run on Redhat 7.0
Status: CLOSED DUPLICATE of bug 18391
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.0
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-14 04:37 EDT by Need Real Name
Modified: 2016-11-24 09:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-14 18:33:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-10-14 04:37:00 EDT
I have just updated to Redhat 7.0 and I am trying to install Oracle 81 
Release 2.  No luck.  I need to get this server going.  What changes have 
been made in Redhat that would prevent Oracle from installing.  Are the 
reports right should I stick with Redhat 6.2?
Comment 1 Alan Cox 2000-10-14 18:33:38 EDT
For the moment 6.2 is a good idea for this. The problem is that Oracle blindly
attempts to relink bits of itself on install and does so without checking that
its relinking modules against the same glibc. Thus it tries to build new modules
versus glibc 2.2 and link them with glib2.1 code. Glibc 2.2 will happily run an
oracle install done under 6.2, but their installer cant cope with the change of
libc
Comment 2 Jakub Jelinek 2000-10-20 10:02:01 EDT

*** This bug has been marked as a duplicate of 18391 ***
Comment 3 Need Real Name 2001-02-07 21:27:58 EST
Actually it is a bug in GLIBC and not a problem with the installer. Oracle links correctly, when running you get a coredump.  Running GDB on the 
coredump you see it is a problem within the glibc file and not within oracle.

Infact, you have to INSTALL the wrong glibc (glibc-compat) and force oracle to link against the OLD glibc for it to even work period.
Comment 4 Jakub Jelinek 2001-02-08 05:36:32 EST
It is not a bug in glibc. Symbol versioning works on linked objects
(programs and shared libraries), not on relocatable files, and if you compile
relocatable objects against one library, you have to link them against the
same library (and then symbol versioning takes care that you can run that
binary/shared library against newer glibc), but this is not true in the Oracle
install process. Before symbol versioning it would not work either. If they
say compiled their stuff against libc5, it would not run if you linked it
against glibc 2.0.

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