Pgadmin - Debian AMD64 compile problem

Author

Debian AMD64 compile problem

Joost Kraaijeveld

2005-11-04, 7:24 am

Hi,

I am trying to compile PgAdmin3 1.4 Beta 3 on a Debian 3.1 Sarge machine
with PostgreQSL 8.03 installed. Configure complains, saying

checking for pgsql include files... yes
checking for pgsql... yes
checking for PQexec in -lpq... yes
checking for SSL_connect in -lpq... yes
checking libpq-fe.h usability... no
checking libpq-fe.h presence... no
checking for libpq-fe.h... no
checking pgsql in /usr... failed
configure: error: you must specify a valid pgsql installation with
--with-pgsql=DIR

Now I am confused. The first two lines suggest that configure finds the
files it cannot find in the last two lines.

Could you give me an insight in what it actually wants, and more
important where to find it?

TIA

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J.Kraaijeveld@Askesis.nl
web: www.askesis.nl

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Dave Page

2005-11-04, 7:24 am

> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of
> Joost Kraaijeveld
> Sent: 04 November 2005 11:25
> To: pgadmin-support@postgresql.org
> Subject: [pgadmin-support] Debian AMD64 compile problem
>
> Hi,
>
> I am trying to compile PgAdmin3 1.4 Beta 3 on a Debian 3.1
> Sarge machine
> with PostgreQSL 8.03 installed. Configure complains, saying
>
> checking for pgsql include files... yes
> checking for pgsql... yes
> checking for PQexec in -lpq... yes
> checking for SSL_connect in -lpq... yes
> checking libpq-fe.h usability... no
> checking libpq-fe.h presence... no
> checking for libpq-fe.h... no
> checking pgsql in /usr... failed
> configure: error: you must specify a valid pgsql installation with
> --with-pgsql=DIR
>
> Now I am confused. The first two lines suggest that configure
> finds the
> files it cannot find in the last two lines.

Ignore the first two - what it really means is that it has a path to
look in for each of those items. I'll look to improving those messages.

> Could you give me an insight in what it actually wants, and more
> important where to find it?

Yeah, it looks like it's finding libpq (which is not always a surpsie if
it's somewhere in LD_LIBRARY_PATH, but failing to find the headers which
it needs the precise location of. You can override the header path with
--with-pgsql-include=/path/to/dir. It expects to find libpq-fe.h (and
any dependencies) in the directory you specify.

I need to refactor the pgsql detection code to try to use pg_config (as
we already do for wx), but that's not going to happen for 1.4.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Joost Kraaijeveld

2005-11-04, 9:23 am

Hi Dave,

> Yeah, it looks like it's finding libpq (which is not always a surpsie if
> it's somewhere in LD_LIBRARY_PATH, but failing to find the headers which
> it needs the precise location of. You can override the header path with
> --with-pgsql-include=/path/to/dir. It expects to find libpq-fe.h (and
> any dependencies) in the directory you specify.
Now I have an executable. Running the executable results in a strange
error:

jkr@Panoramix:~/even/pgadmin3-1.4.0-beta3/src$ ./pgadmin3
Fatal Error: Mismatch between the program and library build versions
detected.
The library used 2.6 (no debug,Unicode,compil
er with C++ ABI 1002,wx
containers,compatibl
e with 2.4),
and your program used 2.6 (no debug,Unicode,compil
er with C++ ABI 102,wx
containers,compatibl
e with 2.4).
Aborted

Any ideas? Could it be that the version of wxWidgeds I installed was
compiled with g++ 4.x and I actually used g++ 3.3.5 as I see that the
ABI version is different (102 vs 1002)?

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J.Kraaijeveld@Askesis.nl
web: www.askesis.nl

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Dave Page

2005-11-04, 11:44 am

> -----Original Message-----
> From: Joost Kraaijeveld [mailto:J.Kraaijeveld@Askesis.nl]
> Sent: 04 November 2005 15:12
> To: Dave Page
> Cc: pgadmin-support@postgresql.org
> Subject: RE: [pgadmin-support] Debian AMD64 compile problem
>
> Hi Dave,
>
> a surpsie if
> headers which
> header path with
> libpq-fe.h (and
> Now I have an executable. Running the executable results in a strange
> error:
>
> jkr@Panoramix:~/even/pgadmin3-1.4.0-beta3/src$ ./pgadmin3
> Fatal Error: Mismatch between the program and library build versions
> detected.
> The library used 2.6 (no debug,Unicode,compil
er with C++ ABI 1002,wx
> containers,compatibl
e with 2.4),
> and your program used 2.6 (no debug,Unicode,compil
er with C++
> ABI 102,wx
> containers,compatibl
e with 2.4).
> Aborted
>
> Any ideas? Could it be that the version of wxWidgeds I installed was
> compiled with g++ 4.x and I actually used g++ 3.3.5 as I see that the
> ABI version is different (102 vs 1002)?

Quite possibly. You normally get that error when pgAdmin is built in
debug mode and wx in non-debug, or static vs dynamic, unicode vs
non-unicode etc. All those errors should now be picked up by configure
following my recent re-working of the wx detection code.

I would try building your own version of wx from source.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Joost Kraaijeveld

2005-11-04, 11:44 am

Hi Dave,

On Fri, 2005-11-04 at 15:25 +0000, Dave Page wrote:
> Quite possibly. You normally get that error when pgAdmin is built in
> debug mode and wx in non-debug, or static vs dynamic, unicode vs
> non-unicode etc. All those errors should now be picked up by configure
> following my recent re-working of the wx detection code.
Do I understand you correctly, if I think you say is *should* go right now?

In an attempt to solve my own question by trying I did:

export CC=/usr/bin/g++-4.0
../configure --with-pgsql-include=/usr/include/postgresql/8.0/
make

This time it did not link (undefined reference to "ScanKeywordLookup")
but more important: it looks like the makefiles do not actually use the
CC variable (it is set in the Makefiles thought): I did a "ps ax" and it
showed that the default system compiler is used and not the compiler I
I CC'ed (I omited most of the output for clarity):

.... g++ -DHAVE_CONFIG_H -I. -I. .....
..../usr/lib/gcc-lib/x86_64-linux/3.3.5/cc1plus -quiet - ...

I have looked into the Makefiles itself, but sorry, I could not figure
out what exactly is done there. Do you know if my observation could be
right?

> I would try building your own version of wx from source.
OK, I will try that.

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J.Kraaijeveld@Askesis.nl
web: www.askesis.nl

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Dave Page

2005-11-04, 11:44 am

> -----Original Message-----
> From: Joost Kraaijeveld [mailto:J.Kraaijeveld@Askesis.nl]
> Sent: 04 November 2005 15:39
> To: Dave Page
> Cc: pgadmin-support@postgresql.org
> Subject: RE: [pgadmin-support] Debian AMD64 compile problem
>
> Hi Dave,
>
> On Fri, 2005-11-04 at 15:25 +0000, Dave Page wrote:
> by configure
> Do I understand you correctly, if I think you say is *should*
> go right now?
>
> In an attempt to solve my own question by trying I did:
>
> export CC=/usr/bin/g++-4.0
> ./configure --with-pgsql-include=/usr/include/postgresql/8.0/
> make

Try:

export CXX=/usr/bin/g++-4.0

> This time it did not link (undefined reference to "ScanKeywordLookup")
> but more important: it looks like the makefiles do not
> actually use the
> CC variable (it is set in the Makefiles thought): I did a "ps
> ax" and it
> showed that the default system compiler is used and not the compiler I
> I CC'ed (I omited most of the output for clarity):
>
> ... g++ -DHAVE_CONFIG_H -I. -I. .....
> .../usr/lib/gcc-lib/x86_64-linux/3.3.5/cc1plus -quiet - ...
>
> I have looked into the Makefiles itself, but sorry, I could not figure
> out what exactly is done there. Do you know if my observation could be
> right?

Yeah, we use CXX, just for added confusion :-)

> OK, I will try that.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Joost Kraaijeveld

2005-11-04, 11:44 am

On Fri, 2005-11-04 at 15:46 +0000, Dave Page wrote:
> Try:
>
> export CXX=/usr/bin/g++-4.0
OK, works, no more confusion.

[color=darkred]
This one is still there. I noticed that the function is implemented in a
C file (keywords.c) and defined in keywords.h as

extern const ScanKeyword *ScanKeywordLookup(c
onst char *text);

It is used in the C++ file misc.cpp. I suspect that is has something to
do with mixing C and C++ and the linkage rules. Do you know by any
chance the linkage rules in the C++ standard for extern const functions
and if this could play a role?

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J.Kraaijeveld@Askesis.nl
web: www.askesis.nl

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Sponsored Links