Thread: difficulty building PostgreSQL with PHP4?
I've just built Apache 1.3.17 on Free BSD, using php-4.0.1pl2 and linking with the PostgreSQL 7.0.3 as a shared object. I created a test database, with proper permissions for the web server. I can query it with psql, and I see a socket as "/tmp/.s.PGSQL.5432=". I also linked in mySQL support, which works correctly. When I try accessing the posters database by calling pg_Connect("dbname=test"), my web server doesn't even display a page, other than "this page cannot be displayed" (in IE) or "page contains no data" (Netscape). The error log displays: (null): Undefined symbol "_PQsetdbLogin" called from httpd:/com/apache/libexec/libphp4.so at 0x8256498 A friend suggested calling pg_Connect with no arguments - if I do that, the page displays with the error "Wrong parameter count for pg_connect()". This implies the postgres library was able to resolve with php, and something else may be the problem when I add arguments. Are there issues with PHP4? Is there a problem building both postgres and mysql support? Should I be using a static module build for PHP, rather than a DSO? thanks.
On Mon, Feb 26, 2001 at 05:18:46PM -0800, some SMTP stream spewed forth: > I've just built Apache 1.3.17 on Free BSD, using php-4.0.1pl2 and linking > with the PostgreSQL 7.0.3 as a shared object. I created a test database, > with proper permissions for the web server. I can query it with psql, and > I see a socket as "/tmp/.s.PGSQL.5432=". > > I also linked in mySQL support, which works correctly. > > When I try accessing the posters database by calling > pg_Connect("dbname=test"), my web server doesn't even display a page, other > than "this page cannot be displayed" (in IE) or "page contains no data" > (Netscape). > > The error log displays: > (null): Undefined symbol "_PQsetdbLogin" called from > httpd:/com/apache/libexec/libphp4.so at 0x8256498 I cannot help you there, other than to say that your problem is not as below. > A friend suggested calling pg_Connect with no arguments - if I do that, the > page displays with the error "Wrong parameter count for > pg_connect()". This implies the postgres library was able to resolve with > php, and something else may be the problem when I add arguments. > > Are there issues with PHP4? I can testify that we have no problems (related to this, of course there is that ever-aggravating persistent-connection mess with PHP) using PHP 4.0.4pl1, with PostgreSQL PostgreSQL 7.0.3 on i386-unknown-freebsdelf4.2, compiled by cc, and MySQL mysql Ver 11.12 Distrib 3.23.33, for -freebsd4.2 (i386). > Is there a problem building both postgres and mysql support? As above, I say that not. > Should I be using a static module build for PHP, rather than a DSO? We use a DSO without issue (related to this, again). > thanks. Bah, it is a mailing list. ;-) Cheers, Dan
Hey, As someone else mentioned, there aren't any issues using this combo (I use it on Linux, not *BSD). >The error log displays: >(null): Undefined symbol "_PQsetdbLogin" called from >httpd:/com/apache/libexec/libphp4.so at 0x8256498 Did you have any problems compiling all of the things together? Just looks like either the libphp4.so file is corrupted (unlikely) or there is a problem with PHP. Maybe try a new version? (currently - PHP 4.0.4pl1 I think). Just a suggestion ------------------------ Chris Smith http://www.squiz.net
Phil Glatz <phil@glatz.com> writes: > The error log displays: > (null): Undefined symbol "_PQsetdbLogin" called from > httpd:/com/apache/libexec/libphp4.so at 0x8256498 This looks like some sort of shared-library link problem. The situation probably is that you have a DSO containing the PHP pgsql interface module, which is loaded by PHP on demand, and which in turn calls the libpq shared library --- so that DSO also has to be loaded to get the whole thing to work. A lot of shared-lib dynamic loaders are pretty unforgiving when it comes to handling indirect shared library dependencies like this. I am not sure just how to fix it on FreeBSD (any FreeBSDers out there?). But if you can't find a proper fix, a workaround would be to link libpq.a into the PHP interface module DSO so that there's only one level of DSO to resolve, not two. regards, tom lane