|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2000-07-27 22:08 UTC] zak@php.net
[2000-07-28 09:28 UTC] m dot brooks at ukonline dot co dot uk
[2000-07-28 11:32 UTC] waldschrott@php.net
[2000-07-28 11:52 UTC] kara@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Dec 19 21:00:01 2025 UTC |
I have RedHat 6.1 Linux, Apache 1.3.12-2 RPM from RedHat, PHP 4.0.1pl2 tarball, unixODBC 1.8.8-1 RPM (Murray Todd's RPM build from the GrapeApe site grapeape.codingpages.com/odbc.xml). I used the following config options: ./configure --with-unixODBC=/usr --with-apxs --without-mysql Note the "/usr" for the unixODBC root, rather than the default of "/usr/local". kpackage shows the unixODBC libs to be placed in "/usr/lib", so I am inferring from this that the base install dir is "/usr". The make and make install appear to run successfully, with the exception of the updating of the httpd.conf file. This erroneously declares mod_php4 as being "usr/lib/apache/libphp4.so", rather than "modules/libphp4.so", so I have to manually edit that. When I start Apache, it immediately falls over with nothing reported in error_log. An httpd -X reports a Segmentation fault. In neither case is a core dumped. Running from within gdb I get the following: [root@localhost sbin]# gdb ./httpd GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)... (gdb) run -X Starting program: /usr/sbin/./httpd -X Cannot access memory at address 0x403d4874. (gdb) bt #0 0x4000a6d1 in _dl_debug_state () at dl-debug.c:56 #1 0x4017c4e6 in _dl_close (map=0x80a69d8) at dl-close.c:195 #2 0x4009d0c0 in dlclose_doit (handle=0x80a69d8) at dlclose.c:26 #3 0x4000a3eb in _dl_catch_error (errstring=0x4009ed00, operate=0x4009d0a8 <dlclose_doit>, args=0x80a69d8) at dl-error.c:141 #4 0x4009d549 in _dlerror_run (operate=0x4009d0a8 <dlclose_doit>, args=0x80a69d8) at dlerror.c:125 #5 0x4009d08e in dlclose (handle=0x80a69d8) at dlclose.c:32 #6 0x806748c in ap_os_dso_unload () #7 0x804f9a0 in ap_get_server_built () #8 0x8051068 in ap_run_cleanup () #9 0x804fe59 in ap_clear_pool () #10 0x805bf76 in ap_child_terminate () #11 0x805c65f in main () #12 0x400b71eb in __libc_start_main (main=0x805c3e0 <main>, argc=2, argv=0xbffffd04, init=0x804f014 <_init>, fini=0x807b99c <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffcfc) at ../sysdeps/generic/libc-start.c:90 (gdb) Note that if I configure PHP without the unixODBC option, everything works fine. One possibility that comes to mind is the php.ini file. The make install does not create one for me, and this certainly does not prevent PHP itself from operating. However, are there any configuration options that must be set up for unixODBC to work? In the absence of any mention of specific unixODBC options in the documentation, I have tried using the unified ODBC options, but to no avail. Regards, Michael Brooks (mailto:m.brooks@ukonline.co.uk)