The problem is at least in the make file of PHP. It only checks for 7.3, 8.0, 8.1 (8i) and 9.0 (9i). It looks at a file in $ORACLE_HOME that has a numeric value in it. In Oracle 10g, this value is 10. I changed the php make file to also recognice the 10, but this alone was not enough to make it find the OCI libraries :( Workaround for now: Install Oracle 9i OCI, then connect to server. I just don't like this, since I'm running Apache2 + PHP on the same Oracle server. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I found in the bugtracker of php these two fixes: http://bugs.php.net/bug.php?id=27117 http://bugs.php.net/bug.php?id=27093 They have been fixed in php 4.3.x-dev on the 1st and 3rd of February. Any changes for an ebuild or a patch?
if you'd care to bundle up the patches and test to confirm that they solve the problem for you, then post the bundled patch here, and we'll include it.
I'm already on it :) There are about 15 lines to be changed in a config file and 5 lines in one c file. Once I have it compiled and did some testing, I will post the patch for it. BTW: It seems that the upcoming 4.3.5 will already have this in it :)
Created attachment 26403 [details, diff] Small patch to get Oracle 10g working in PHP 4.3.4
Created attachment 26404 [details] My modified ebuild script
Here are the micro patch to get Oracle 10g connections correctly working (dword -> dvoid changes) and the updated config.m4 file, to correctly detect Oracle 10g. In the ebuild file, I just added these lines: ---start--- # to enable Oracle 10g OCI8 detection epatch ${FILESDIR}/oracle10g_enable.diff # needs updated configure rm configure ./buildconf --force ---end--- The only ugly thing is: I had to delete "configure" and rebuilt it, otherwise the detection for Oracle 10g wouldn't be in it. I also tested it and it worked! (Connection to database, parsing of query, execution of statement, 4 rows retrieved, statement freed, connection closed). From my point of view: it works. To night, I will write a small test to check, if stored procedures work or not.
As a matter of fact, instead of hacking the config.m4 file and rerunning buildconf, you could just patch the configure script itself. Buildconf is a rather expensive process, and i'd rather avoid it in the ebuild.
That is true, and that is really the only ugly downside of the patch :) I didn't know how important the configure file is and weither or not it was modifed to fit gentoo specific aspects. I will try to get a good patch against the configure file and submit it here. PS: oci8.c needs to be patched anyway.
I now made a backup of the configure that comes with the ebuild. Then I deleted it and run "./buildconf --force" The I generated a "smaller" diff be running "diff -du configure.orig configure.new" The resulting diff is 3.1 MB !! Maybe the configure in gentoo was built different! Or should I attach the 3.1 MB file? (When gzip`d it is only 294 kb)
Could you please attach it (or put it somewhere online). I believe that most of it is due to whitespace changes or similiar.
Might also be because buildonf reorders things in the configure script (and then we'll just need to edit the configure script manually to get a smaller patch).
Created attachment 26601 [details] The diff against my new Oracle 10g enabled configure
I attached the diff. (I got by rebuilding configure) I hope PHP 4.3.5 is released soon, that there is not need for the patch anymore since it will be included as well as many other updates :)
This has been fixed in php-4.3.5. Closing bug. (I know that we don't have a php-4.3.5 ebuild yet) Best regards, Stu
