Customer-built liboraapi11.so needs correct Oracle libraries

When building a new liboraapiNN.so GemConnect library on a Solaris or AIX
system that has both 32-bit and 64-bit Oracle installed, the customer must
be careful to configure the building and execution of the liboraapiNN.so
library so that the correct Oracle 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 liboraapiNN.so is built and/or executed using the
Oracle 64-bit libraries in $ORACLE_HOME/lib, the topaz/gem session will
fail when the session attempts to login to Oracle.  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 liboraapi11.so, 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 liboraapiNN.so 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.

Workaround:

none/not applicable