Skip site navigation (1) Skip section navigation (2)

Re: Issue with libpq < 8.4

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Issue with libpq < 8.4
Date: 2010-08-26 10:02:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Thu, Aug 26, 2010 at 10:51 AM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> Le 26/08/2010 11:49, Dave Page a écrit :
>> On Thu, Aug 26, 2010 at 10:48 AM, Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info> wrote:
>>> What I've come to is this patch. Actually, and quite surprisingly, it
>>> doesn't work. I have no idea why. The configure script finds if we have
>>> or not the PQconninfoParse function(), but the #ifdef in pgConn source
>>> file doesn't seem to do what it has to. I always get a build without
>>> PQconninfoParse, wether configure founds it or not.
>>> Any ideas on what I did wrong?
> Oops, time to get some coffee, as you already said :)

There's two ways you can fix it. To match what we do for SSL support:

In acinclude.m4, you don't need to use AC_SUBST, and you do need to
add something like:

                if test "$PG_SSL" = "yes"
                        CPPFLAGS="$CPPFLAGS -DSSL"

but for HAVE_CONNINFOPARSE (yes, I know we should probably do this in
CXXFLAGS, but now is not the time to fix the build system :-p ).

The other way uses AC_SUBST to add the variable to the Makefile (which
you did). You can then use that variable in to
conditionally add the -DHAVE_CONNINFOPARSE. Iirc, that's similar to
have we deal with the options to build an appbundle.

Dave Page
Twitter: @pgsnake

EnterpriseDB UK:
The Enterprise Postgres Company

In response to


pgadmin-hackers by date

Next:From: Magnus HaganderDate: 2010-08-26 10:15:00
Subject: Re: Issue with libpq < 8.4
Previous:From: Guillaume LelargeDate: 2010-08-26 09:51:16
Subject: Re: Issue with libpq < 8.4

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group