php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #4615 Apache refuses to load libphp4.so; "undefined symbol SQLParamData"
Submitted: 2000-05-26 17:03 UTC Modified: 2000-11-22 10:40 UTC
From: george dot stone at mail dot sprint dot com Assigned: kalowsky (profile)
Status: Closed Package: Solid related
PHP Version: 4.0.0 Release OS: Debian 2.0
Private report: No CVE-ID: None
View Developer Edit
 [2000-05-26 17:03 UTC] george dot stone at mail dot sprint dot com 
Compiling PHP 4.0.0 as DSO in Apache 1.3.11.  Compilation and install goes through fine.  When stopping and starting the server I recieve the following message:

Syntax error on line 239 of /usr/local/httpd/conf/httpd.conf:
Cannot load /usr/local/httpd/libexec/libphp4.so into server: /usr/local/httpd/li
bexec/libphp4.so: undefined symbol: SQLParamData
/usr/local/apache/bin/apachectl start: httpd could not be started

ldd on the old libphp3.so reveals:

kcased03# ldd /usr/local/apache/libexec/libphp3.so
        libgdbm.so.1 => /usr/lib/libgdbm.so.1 (0x4013d000)
        /usr/local/solid/lib/scll2x23.so => /usr/local/solid/lib/scll2x23.so (0x
40143000)
        libm.so.6 => /lib/libm.so.6 (0x401c6000)
        libdl.so.2 => /lib/libdl.so.2 (0x401e4000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x401e8000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40215000)
        libc.so.6 => /lib/libc.so.6 (0x40224000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40300000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)

ldd on the new libphp4.so reveals:

kcased03# ldd /usr/local/apache/libexec/libphp4.so
        libgdbm.so.1 => /usr/lib/libgdbm.so.1 (0x4010a000)
        libdl.so.2 => /lib/libdl.so.2 (0x40110000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40114000)
        libm.so.6 => /lib/libm.so.6 (0x40124000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40141000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4016e000)
        libc.so.6 => /lib/libc.so.6 (0x40184000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)

The Solid library does not appear to be linked in.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-07-24 16:31 UTC] kalowsky@php.net 
same as bug #3628
 [2000-07-26 18:34 UTC] kalowsky@php.net 
finally was able to reproduce this bug.
interesting solutions found for this entry.

1) force php to load the .a instead of the .so file

2) force Apache to load the module with the LoadFile command BEFORE the LoadModule modphp line in your httpd.conf file.  

initial examination leads us to believe that Apache doesn't seem to be fully loading all the shared objects.  although this could also be a case of PHP not linking in properly... further investigation is being conducted.
 [2000-08-24 17:14 UTC] kalowsky@php.net 
good news is, i've finally been able to figure out a better solution to this problem.  thanks in part to bruce baumann.  

unfortunately due to the nature of this change, it will not be implemented until sometime after 4.0.2 is released.

in preparation, and in part as a note to myself or whoever else feels they want to fix this i'll outline the basics below:

in your solid lib dir, create a link pointing to your solid library file, called libsolodbc.so.3 
next create a secondary link to it called libsolodbc.so  (a little backwards, but I haven't been able to get Solid libs to be recognized any other way).

next change the ext/odbc/config.m4 to have: ODBC_LIBDIR=$with_val/lib
ODBC_LFLAGS=-L$ODBC_LIBDIR
ODBC_LIBS="-lsolodbc"

remove pretty much everything else on selecting the library file as its useless now...remove the first Solid function (this can all be done in the second).  now enjoy.  

Like i've said a bit complicated, and thus it will wait until AFTER the 4.0.2 release, unless some of the PHP core members request otherwise...
 [2000-11-22 10:40 UTC] kalowsky@php.net 
With recently submitted patch to the ext/odbc/config.m4 this should be gone!  Tested on 3.5 and 3.0, but not 2.3.

Thanks to Eric Veldhuyzen for creating, testing, and altering the patches between ourselves.  

This does not take care of the bug #7922, which will cause a WVARCHAR to crash the system.  So don't call your SYS_TABLES via PHP and Solid just yet (or more than likely, ever).

Marking as closed for now...
 [2004-10-13 12:56 UTC] tg at 66h dot 42h dot de 
I'd like to re-open this bug for PHP 4.3.9, Empress DB v8.60

Same problem, same symbol not found.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Oct 30 21:00:01 2025 UTC