Customer-built liboraapi library needs to link to correct Oracle libraries
When building a new liboraapi GemConnect library on a system that has both
32-bit and 64-bit Oracle installed, the customer must be careful to configure
the building and execution of the liboraapi library so that the correct
Oracle 32 or 64 bit libraries are used.
In a dual 32- and 64-bit Oracle installation, the 32-bit libraries are
stored in $ORACLE_HOME/lib32, while the 64-bit versions are stored in $ORACLE_HOME/lib.
If the liboraapi library is built and/or executed using the wrong Oracle
libraries, the topaz/gem session will fail when the session attempts to
login to Oracle. For example, on Solaris, GemStone error #rtErrUalibLoadFailed
(2171) will be raised with the message:
wrong ELF class: ELFCLASS64
while on AIX, the session will crash with a SIGILL exception and core dump.
To avoid this, do the following:
1. While building the liboraapi library, the supplied Makefile must be
modified as explained in the comment fields. The relevant
portion is:
----------------------------------------------------
ORALIB = $(ORACLE_HOME)/lib
# When 64-bit Oracle is installed,
# use the following definition of ORALIB instead:
# ORALIB = $(ORACLE_HOME)/lib32
----------------------------------------------------
In this case, the first ORALIB definition should be commented
out and the later definition uncommented, so that it reads as:
----------------------------------------------------
# ORALIB = $(ORACLE_HOME)/lib
# When 64-bit Oracle is installed,
# use the following definition of ORALIB instead:
ORALIB = $(ORACLE_HOME)/lib32
----------------------------------------------------
2. When executing the customer-generated liboraapi library in GemStone,
the $LD_LIBRARY_PATH environmental variable for the user executing
the topaz/gem process should include $ORACLE_HOME/lib32 and *not*
$ORACLE_HOME/lib.
Last updated: 4/9/14