- Installed SRPMs for apache (1.3.6-8), mod_php3 (3.0.8-1) and MySQL (3.22.22-1); (MySQL SRPM came directly from www.tcx.se) - compiled MySQL rpms, all went fine. Built and installed without error. MySQL seems to be completely stable (so far :-) - edited mod_php3.spec, added "--with-mysql" to configure command. Built and installed without error. - rebuilt/installed apache without error - rebuilt/reinstalled mod_php3 (just in case, 'cuz I just reinstalled apache-devel... wasn't sure if there were any dependencies) So far, so good... mod_php3 is compiled with MySQL support, apache dynamically loads mod_php3 correctly, everything seems OK. Accessing PHP3 pages that do database access causes apache to report: [Thu Jun 3 21:19:41 1999] [notice] child pid 22534 exit signal Segmentation fault (11) there also appears to be a bug in calling external programs from php3, as if I attempt to execute "/usr/bin/mysqladmin --user=root --password= -- host=localhost --port= version" from inside a PHP page, I *also* see in the error_log: sh: /mysqladmin: No such file or directory sh: /mysqladmin: No such file or directory sh: /mysqladmin: No such file or directory immediately followed by a notice of a child SEGVing. I know php3.0.8 changed a couple of things related to glibc2.1; I'm wondering if this could be another glibc2.1- related issue? Incidentally, this box was *supposed* to be my production server.... *sigh*
Forgot to mention: when provoking this bug, I do frequently get "document has no data" errors from Netscape. The child is indeed sometimes dying before it outputs data!
I take it this worked in previous PHP3 RPMs? We have no experience with MySQL.
Actually, the last working configuration was RH5.2; further investigation has revealed that PHP 3.0.8 and newer have some problems with MySQL on Intel gcc- and egcs- based platforms. Rolling back to PHP 3.0.7 fixes the problem on everything EXCEPT RedHat 6.0, since 3.0.7 breaks with glibc2.1.
this should be resolved with php 3.0.12, available in RawHide (and the next release, eventually). Please open this bug again if this is not the case.