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.

same as bug #3628

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.

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...

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...

I'd like to re-open this bug for PHP 4.3.9, Empress DB v8.60

Same problem, same symbol not found.