On Thu, Feb 12, 2004, Julien TOUCHE wrote:
> few comments on an apache setup with current/solaris9 (php part)
>
> - oci8 support
> [...]
> checking Oracle version... configure: error: Oracle-OCI8 needed
> libraries not found
> [...]
> and php*.src.rpm compiles fine with oci8
> $ rpm -qi php|grep oci
> php::with_oci7 = no
> php::with_oci8 = yes
Hmmm... I've installed "apache" with "oracle-barebone" (i.e. OCI8
support) just a last week on a Solaris 9 box. Can you dig deeper (look
into file config.log) why it does not find the OCI8 libs.
> (oracle-*.rpm is installed)
Ah, you using "oracle" only and you have an own Oracle installation or
are you using "oracle" together with "oracle-barebone"? I've only tried
it with "oracle-barebone" recently and never with a regular installation
myself.
> - why gdbm in apache, by default ? (with_gdbm_ndbm)
Because of cross-platform compatibility. Not all platforms provide the
NDBM API and we have to be consistent across platforms.
> - 2 extra security mods: patch to add mod_security & mod_dosevasive
I'll look at this.
> - MTA/apache: one forgotten
> 215 %if "%{with_mod_php}" == "yes"
> 216 BuildPreReq: gcc, sed, flex, bison
> 217 PreReq: MTA
Ops, good catch. Will be fixed.
> - core on browser access with mod_dav
> [Thu Feb 12 14:23:55 2004] [notice] child pid 29154 exit signal
> Segmentation Fault (11), possible coredump in /home/www-
> test/local/var/apache
> [Thu Feb 12 14:24:09 2004] [notice] child pid 29155 exit signal
> Segmentation Fault (11), possible coredump in /home/www-
> test/local/var/apache
Well... this might be certainly mod_dav's fault because it segfaulted in
the past under Solaris sometimes if "sufficient enough" other modules
are enabled. I think it was a problem with mod_perl or mod_php, but I do
not know it exactly anymore. I've currently no patch available to fix
this. One has to dig deeper to find the problem.
> Core was generated by `/home/www-test/local/sbin/apache'.
> Program terminated with signal 11, Segmentation fault.
> Cannot access memory at address 0xff3f73a4
> #0 0x002a2794 in dav_add_response ()
> (gdb) where
> #0 0x002a2794 in dav_add_response ()
> Cannot access memory at address 0xffbff7cc
> (gdb)
Ah, that's nice. Can you perform a backtrace ("bt") and
print a few variables from the context of this function.
Perhaps we then find the bug in the source of mod_dav.
> ok with mod_dav disabled
Yes, I that was also my experience from over one year ago.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
