Re: WORKING!! :) oci8 & apache mod (4.0.2 release) -

From: Date: Tue, 05 Sep 2000 21:00:45 +0000
Subject: Re: WORKING!! :) oci8 & apache mod (4.0.2 release) -
References: 1 2 3 4 5 6 7  Groups: php.windows 
Request: Send a blank email to php-windows+get-2437@lists.php.net to get a copy of this message
Daniel Beulshausen wrote: > no worries :) i'll have a look at the oracle technet maybe they're stored > there somewhere. > but i still think this has something to do with the directory support... Solved It!!!!!! Apache 3.1.12 & PHP4.0.2 Release working as Apache module with oci8 support! Teehee... man that was a tough one. One more thing to look out for is your setting of "extension_dir". If you don't set this in the correct FORMAT, then oci8 will kill apache service on load. Very odd, but anyway, here's what happened in debuggin today... **** My original mail which I was writing as I tested stuff, but solved before sending *** OK, moving this a step further... after fighting for a day-or-so on trying to OVERRIDE apache's path environment, and getting nowhere (I can't seem to get this service to start with my own specified PATH value... hmmmm), I decided to try something else. First, as soon as I uncomment (add) php_oci8.dll in php.ini and restart apache service, crash with non-specific "service not responding to control function" error. Keeping php as apache module, I decided to MOVE my copies of oci.dll and ociw32.dll from c:\oracle\ora81\bin to a different non-pathed directory - just to see if Apache would find them, or if the error messages would change on startup of the apache service. And they did... with oci.dll OUTSIDE the computer's specified path (which apache is still seeing as "c:\oracle\ora81\bin;<therest>") Apache gives the following messages 1) standard LONG message of "Could not locate OCI.dll in path <all of my system path which is quite long referenced with backslashes>" and 2) short message (from php) of "Unable to load dynamic library '\php\extensions/php_oci8.dll' - The specified module could not be found." Two odd things though: 1) why does this message show backslashes for the first two directories and then a frontslash in front of the extension, and 2) I get the same sequence of two dialogs THREE TIMES for the same "OCI.dll" - any clue why it might issue this 3 times? However, the service continues to load at this point without the php_oci8 support. Next, move oci.dll BACK into system pathed oracle directory, and crash... it didn't even get to the point of looking for ociw32.dll. ***** end of the message I WAS composing :) **** So, the one thing I thought to try was look at my "extension_dir" setting in php.ini, and indeed IT was set to the odd "\php\extensions" instead of "c:/php/extensions" as Daniel originally had it in php-ini.dist. Duh! So, on a hunch I reset the extension_dir setting to "c:/php/extensions/", with php_oci8 included in my extensions section, then restarted apache as service with php module and... drum roll... everything worked! Thus another KEY FACTOR in php4/apache/oci8 support is having ALL front-slashes in your php.ini settings... doesn't matter what the external PATH is (as long as apache & php can see your oci8 dlls) but you MUST have front-slashes in your extension dir settings or kaboom! Now I'm going home, as I think that was enough of an accomplishment today. So, just to prove that it is possible... I've got the following running (cool!) php4.0.2 release (php4win.de binaries & extensions) apache 3.1.12 loading php4apache.dll (from above release) Zend Optimizer .99 for php4.0.2 php_oci8 extension loading with Oracle 8.1.6 Client Man that took a lot, but worth it. I'll write that all down sometime this week. -- Andy Hoffman Web Developer Bristol-Myers Squibb email: andy.hoffman@bms.com

« previous php.windows (#2437) next »