./configure should be able to detect the Oracle Instant Client

[hobu]

The oracle instant client is an rpm-based distro of libs and headers (split into
a few rpms, actually) that allow you to install all you need on linux, etc to be
able to make connections to oracle.  This allows you to work without an
ORACLE_HOME directory defined and without all of the headaches of installing
things using the java installer.

Our configure needs to be able to detect the common places where the instant
client is usually installed.  This is /usr/include/oracle/version.0.0/client and
/usr/lib/oracle/version.0.0/client/lib

On some platforms, the instant client is the *only* way you can get a working
oracle client install (Fedora 2, IIRC).

[dmorissette]

I can assist with the required configure.in changes if you need help, but I am
not setup to test with Oracle.

[hobu]

Daniel,

Instant client can be grabbed from http://www.oracle.com/technology/tech/oci/instantclient/
instantclient.html

All you should have to do is install them into their default locations and make configure.in be able to find 
them.  No need to test against a real Oracle database directly as long as they build and link.

Thanks

Howard

[fsimon@…]

Hi folks,
I just can start to work on this feature only next week, I'm doing a course 
this week an just go back to lab on Monday.  
This bug is related with bug# 1470, I believe that just a simple configure 
checks will solve this problem because the maporaclespatial.c works without 
problem with instant client.
Regards.

[dmorissette]

See bug 1470 for the details of this bug's fix.

*** This bug has been marked as a duplicate of 1470 ***

[sdlime]

Some local folks have been screwing around with Oracle via a Mac and reported 
the following issue that falls under this bug. The patch below fixes it. I can 
apply if ok with folks...

1) On MacOS X 10.4 with Oracle Instant Client, I had to add a line to  
configure.in so that configure would find libclntsh. This is because  
the Mac uses ".dylib" and not ".so" for the shared library extension.

--- configure.in        2006-03-30 17:32:23.000000000 -0600
+++ ../../mapserver-4.8.3/configure.in  2006-05-24 08:48:50.000000000  
-0500
@@ -1353,6 +1353,7 @@
    test -f $ORA_HOME/lib/libclntsh.so && ORA_LIBDIR="$ORA_HOME/lib"
    test -f $ORA_HOME/libclntsh.so &&     ORA_LIBDIR="$ORA_HOME"
    test -f $ORA_HOME/lib/oracle/10*/client/lib/libclntsh.so &&  
ORA_LIBDIR=`dirname $ORA_HOME/lib/oracle/10*/client/lib/libclntsh.so`
+  test -f $ORA_HOME/libclntsh.dylib && ORA_LIBDIR=$ORA_HOME
    if test -z "$ORA_LIBDIR" ; then
      AC_MSG_ERROR([Oracle Spatial: libclntsh.so not found.])

Steve

[hobu]

go for it

[dmorissette]

Should you not test all 3 possible locations using the .dynlib extension?

Actually, in all other places in the configure.in where we test for .so files,
we also test for .sl. Is there a .sl symlink pointing to the .dynlib on the Mac? 

See for instance this test for libpng:

test -f $PNG_DIR/lib/libpng.a -o -f $PNG_DIR/lib/libpng.so -o -f
$PNG_DIR/lib/libpng.sl && PNG_LIBDIR="$PNG_DIR/lib"

We could/should change the Oracle tests to use:

  test -f $ORA_HOME/lib/libclntsh.so -o -f $ORA_HOME/lib/libclntsh.sl &&
ORA_LIBDIR="$ORA_HOME/lib"
  test -f $ORA_HOME/libclntsh.so -o -f $ORA_HOME/libclntsh.sl &&    
ORA_LIBDIR="$ORA_HOME"
  test -f $ORA_HOME/lib/oracle/10*/client/lib/libclntsh.so -o -f
$ORA_HOME/lib/oracle/10*/client/lib/libclntsh.sl && ORA_LIBDIR=`dirname
$ORA_HOME/lib/oracle/10*/client/lib/libclntsh.so`