Omnis Technical Note TNSQ0014 Updated January 2009

Configuring Oracle DAM(s) on Linux

For Omnis Studio
By Gary Ashford, Omnis Engineering

Problem

"The Oracle DAM shipped with Omnis Studio for Linux appears to have a version of Oracle clientware hard-coded into it. When starting Omnis, the DAM does not load because the version of Oracle clientware I am using is different."

Details

When we build the Oracle DAM using the Linux compiler and linker tools (gcc and ld), the linker resolves the name of the client library we are linking against to the particular library on the build machine, e.g.
When Oracle 11g client is installed, this will be libclntsh.so.11.1
This happens even if we rename libclntsh.so.11.1 to libclntsh.so or when the DAM is linked via a symbolic link which in turn points to the target library. The former seems to occur because the linker picks up the verbose library name embedded into the Oracle client library.

Thus, it is not currently possible for us to produce an Oracle DAM which simply links against a generic "libclntsh.so" library; the ideal scenario, because Oracle clientware otherwise follows the Linux convention whereby a symbolic link is shipped along with the target library, e.g.

ls -al              
lrwxrwxrwx 1 user users
17
2008-03-04
14.08
libclntsh.so -> libclntsh.so.11.1
-rwxr-xr-x 1 user users
35295891
2007-08-01
12.57
libclntsh.so.11.1

You can display the version of Oracle client which the Oracle DAM requires by navigating to the Omnis/xcomp folder and executing:

ldd damora8.so
  linux-gate.so.1 => (0xffffe000)
libclntsh.so.11.1 => not found
omnisxi.so => /usr/lib/omnisxi.so (0x40a7b000)
libm.so.6 => /lib/tls/libm.so.6 (0x40b00000)
libc.so.6 => /lib/tls/libc.so.6 (0x40b23000)
libwtc9.so => /home/oracle/OraHome92/lib/libwtc9.so (0x40c39000)
libdl.so.2 => /lib/libdl.so.2 (0x40c3c000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40c41000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40c53000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x40c69000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x40c7c000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40c99000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40d96000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40d9e000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40dac000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40dd6000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40df5000)
libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x40e64000)
libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x40e95000)

Solution

To resolve the missing library dependency, you need to create a symbolic link to the Oracle client library on your system and ensure that the filename matches that required by the DAM (see above).
You further need to ensure that the symbolic link you create is in a location where the Linux dynamic linker will find it, e.g. in a location specified by the LD_LIBRARY_PATH environment variable or on the standard library search path (/usr/lib & /usr/local/lib).

su  root
cd  /usr/lib
ln  -s  /home/oracle/OraHome92/lib/libclntsh.so.9.0  libclntsh.so.11.1

or

su  root
cd  /home/oracle/Ora_Home1
ln  -s  /home/oracle/OraHome92/lib/libclntsh.so.9.0  libclntsh.so.11.1

The above example assumes that the Oracle DAM requires libclntsh.so.11.1 and that the library installed on your system is libclntsh.so.9.0 and is located as shown. After creating the symbolic link, check that it points to the correct library (using ls -al). You can also verify that the linker will find the library by navigating to the Omnis/xcomp folder and executing ldd damora8.so again.

The dependency should now be resolved and the Oracle DAM should load when Omnis Studio starts.