Sent on behalf of Sheryl Bruggy:
Many thanks to those people who responded to my questions about combining
PHP/Oracle/Apache/Tru64Unix.
THE PROBLEM
-----------
I am using an Alpha 250, running 4.0E, Oracle 8.0.6 and Apache 1.3.12
compiled with a number of DSO modules including PHP (with support for
MySQL). All worked well until I tried to add support for Oracle into the
PHP build. It compiles and loads with no errors, but Apache will not run.
I have tried using PHP3 (enable-oracle) and PHP4 (enable-oci8) but both
have the same problem.
I have also updated our versions of bison, gcc and gld but with no
success.
NOTE: Oracle is only installed as a client as the database is on another
machine, but I have added the ORACLE environment variables to a wrapper
script which starts the Apache Server.
.......................................................................
THE RESPONSES
-------------
From: Christopher Davis <ckd_at_ckdhr.com>
We had the same problem, which appears to be a lingering issue (I'm not
even sure whether it's an Apache, Oracle, PHP, or Tru64 bug). The
workaround we used was to link PHP into Apache directly rather than as
a DSO.
.................................................................
From: Ecce Potestas Casei <chewy_at_iowatch.com>
I couldn't get oracle support for apache as a DSO. I had to compile php
into the apache binary, which, whilst a complete pain in the arse,
actually works.
..................................................................
From: Frank Wortner <frank_at_bondnet.com>
I have had a similar problem with Informix/PHP/Apache in the past. In my
case, it turned out to be that LD_LIBRARY_PATH was not set at runtime,
so some Informix shared libraries could not be located and Apache would
not start. Perhaps Oracle has a similar issue?
..................................................................
From: Tim Mooney <mooney_at_dogbert.cc.ndsu.NoDak.edu>
Someone asked this question a while back, I answered it, but they never
summarized (that I saw). Did you search the archives and contact them?
We've seen it, and I know one of the common reasons why it happens.
Are you also setting the LD_LIBRARY_PATH in the startup script? Your
php SO depends on an oracle SO, I think something like libclnt.so.1.0.
That shared object isn't in the loader's search path, and even if you
manage to build your php SO with a built-in DT_RPATH that causes it to
look in the appropriate oracle directory, it won't currently work because
of the way the runtime loader works on Tru64 (that's going to be changing
in the future).
The solution is to get to the point where the runtime loader can find the
missing Oracle SO. Setting an LD_LIBRARY_PATH in your apache startup
script might (should?) do it.
An alternate solution, which I absolutely abhor, would be to do
cp -p /path/to/oracle/shared/libraries/libclnt.so.1.0 /usr/shlib/
This installs a non-system shared library in a system directory, which
is a big mistake 99% of the time. As long as your don't make a habit
of doing this and you document what you've done for your coworkers, it's
probably the solution that will cause you the least headaches down the
road, though, especially if there are other software bits (e.g. perl's
DBD::Oracle) that might need the Oracle shared object too.
There may be other reasons why php isn't working for you, but I would
wager that this is the most likely problem.
......................................................................
THE SOLUTION
------------
As I had already set the LD_LIBRARY_PATH as part of my start-up script,
I dont think this was the issue. Unfortunately, I did not get a chance to
try copying the Oracle SO into the shared library, as I had already
completed the suggested workaround before I received Tom's email.
I built PHP into the Apache binary (as a static module) and it now works
fine.
Once again, thanks to those people who took the time to help.
Regards
Sheryl Bruggy
Systems/Network Administrator - Unix
Southern Cross University
Received on Mon Nov 27 2000 - 00:05:41 NZDT