Обсуждение: 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