Compiling PHP, OCI8 on Sparc64 Solaris 10 with Oracle10g

This problem beat me about the head for most of yesterday until I worked out that PHP 5.0.5 doesn’t actually know about Oracle 10.    8 and 9, sure thing – otherwise it decides it is an older version (very silly).

The other problem is that when PHP tries to link to the oracle client libraries, by default it attempts to link against the 64 bit libraries – which with PHP being a 32bit app just isn’t going to fly.

So here I will attempt to guide you in all that is good with PHP and Oracle 10.

The first thing to do is ensure you have a working Solaris 10 install with Oracle 10g already
installed.   As this was to be an actual server machine I installed the full database server including client libraries (which happens by default when you install server).  However the purpose of this is not to help you install Oracle – there are plenty of guides out there for that.  This is to help you get PHP compiled in this environment – there are no guides for that.

So lets unpack the PHP source:
#->tar xf php-5.0.5.tar
#->cd php-5.0.5
php-5.0.5-#->

Now, If you run a straight ./configure –with-oci8 it will most likely fail being unable to find the oracle install:
checking Oracle version… configure: error: Oracle (OCI8) required libraries not found

We need to tell it where to find the oracle libraries.
./configure –with-oci8=/u01/app/oracle/product/10.2.0/Db_1
(assuming this is where your default database was installed to)

This will enable configure to complete.

Next, naturally, we try to make php – all should go well right up until the final link:
php-5.0.5-#->make
… [snip] …
ld: fatal: file /u01/app/oracle/product/10.2.0/Db_1/lib/libclntsh.so: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to sapi/cgi/php
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php] Error 1

This fails because PHP has decided to link against lib/libclntsh.so when it should have linked against lib32/libclntsh.so

No amount of adding –includedir= and –libdir= on the configure command will result in make doing the right thing and linking against the lib32 version.

The solution? We need to edit the configure script to tell it that lib isn’t the be-all and end-all of oracle libraries.  This is a pain, I know, but hopefully the PHP people will fix this for 5.0.6 and above.

At line 64660 in configure you will see the line:
  elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then

Change /lib/ to /lib32/

And at line 69134 you’ll notice that it is missing any reference to Oracle 10.1, so we need to add it – add the following two lines just before the 9.0 line:
  elif test -f $ORACLE_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then
    ORACLE_VERSION=10.1

At line 64977 change:
  if test -z "$OCI8_DIR/lib" || echo "$OCI8_DIR/lib" | grep ‘^/’ >/dev/null ; then
    ai_p=$OCI8_DIR/lib
to:
  if test -z "$OCI8_DIR/lib32" || echo "$OCI8_DIR/lib32" | grep ‘^/’ >/dev/null ; then
    ai_p=$OCI8_DIR/lib32

Line 64368: add
  OCI8_SHARED_LIBADD="-L$OCI8_DIR/lib32"
  LIBS="$LIBS -L$OCI8_DIR/lib32"

Now make clean;
cd to your database and rename the lib directory to lib.unused temporarily so that PHP cannot link against it and leave the lib32 one as is.

Switch back to php dir. Run your configure command, make (which should now complete) and make install.

Go back and rename the lib.unused back to lib as other things will need this to exist.

Finally, make sure you add the lib32 path to your LD_LIBRARY_PATH variable before starting apache/php

LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/u01/app/oracle/product/10.2.0/Db_1/lib32"

Your PHP should now be working fine.

Files to help: My "configure" command:
‘./configure’
‘–prefix=/usr/local/apache2’
‘–includedir=/space/app/oracle/product/10.2.0/Db_1/rdbms/public’
‘–oldincludedir=/space/app/oracle/product/10.2.0/Db_1/rdbms/public’
‘–libdir=/space/app/oracle/product/10.2.0/Db_1/lib32’
‘–with-apxs2=/usr/local/apache2/bin/apxs’
‘–with-oci8=/u01/app/oracle/product/10.2.0/Db_1’

Diff of the configure script to the regular one supplied with PHP 5.0.5
#->diff php-5.0.5/configure php-5.0.5-working/configure                           6:39AM
64367a64368,64369
>   OCI8_SHARED_LIBADD="-L$OCI8_DIR/lib32"
>   LIBS="$LIBS -L$OCI8_DIR/lib32"
64660c64662
<   elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then

>   elif test -f $OCI8_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then
64977,64978c64979,64980
<   if test -z "$OCI8_DIR/lib" || echo "$OCI8_DIR/lib" | grep ‘^/’ >/dev/null ; then
<     ai_p=$OCI8_DIR/lib

>   if test -z "$OCI8_DIR/lib32" || echo "$OCI8_DIR/lib32" | grep ‘^/’ >/dev/null ; then
>     ai_p=$OCI8_DIR/lib32
69133a69136,69137
>   elif test -f $ORACLE_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then
>     ORACLE_VERSION=10.1

Note to PHP developers if they read this – this patch is not one that can be dropped into the regular build – it will only help people who have difficulty installing PHP with OCI8/Oracle10 on Solaris10.

I hope this proves useful to others – it took me >24 hours work to get to this point.

3 Replies to “Compiling PHP, OCI8 on Sparc64 Solaris 10 with Oracle10g”

  1. Hi,

    I have similar platform with you, only different PHP version 4.2.2.
    And I’ve modified /lib to /lib32 and success.
    But, we found another error:

    —————————-
    ld: fatal: library -lclntsh: not found
    ld: fatal: File processing errors. No output written to .libs/libphp4.so
    *** Error code 1
    make: Fatal error: Command failed for target `libphp4.la’
    —————————-

    Googling found, it migh be 64bit issue.
    But refer to Sun Release note (http://docs.sun.com/app/docs/doc/817-0552/6mgbi4fhe?a=view), 64bit and 32bit package is bundled in single package.

    How we modified this clntsh library on configure file?
    Any hint?

    Thanks in advance.

    Regard,
    [bayu

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

All content © Paul Gregg, 1994 - 2024
This site http://pgregg.com has been online since 5th October 2000
Previous websites live at various URLs since 1994