Re: Hokey wrong versions of libpq in apt.postgresql.org - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Hokey wrong versions of libpq in apt.postgresql.org
Date
Msg-id 20140812154924.GB6826@msg.df7cb.de
Whole thread Raw
In response to Re: Hokey wrong versions of libpq in apt.postgresql.org  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Re: Joshua D. Drake 2014-08-11 <53E83E9C.6030107@commandprompt.com>
> The issue that I specifically ran into is that by using apt.postgresql.org
> in its default configuration, I can't add certain extensions (without
> jumping through hoops). Simple:
> 
> Assume a running 9.2.9 from apt.postgresql.org
> apt-get install pgxnclient
> sudo pgxnclient install pg_repack
> 
> ....
> 
> Doesn't work. Because it is looking for libs in /var/lib/postgresql/9.2 not
> /var/lib/postgresql/9.3.
> 
> It also failed on another extension (but I don't recall which one it is).

I'd be interested in which other extension this is. As I told you
repeatedly, we are building tons of extensions for something like 5
branches in parallel on apt.postgresql.org, and things generally just
work.

We don't have pg_repack packages there, but there is pg_reorg. This
indeed required some patch to compile, namely manual pg_config_ext.h
and postgres_ext.h includes:
http://anonscm.debian.org/cgit/pkg-postgresql/pg-reorg.git/tree/debian/patches/headers

Trying pg_repack manually here yields this:

pg_repack-1.2.1/bin $ make
gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -pie -Wall
-Wmissing-prototypes-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing
-fwrapv-fexcess-precision=standard -g -I/usr/include/postgresql -DREPACK_VERSION=1.2.1 -I. -I.
-I/usr/include/postgresql/9.1/server-I/usr/include/postgresql/internal -D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ=0
-D_GNU_SOURCE-I/usr/include/libxml2  -I/usr/include/tcl8.5  -c -o pgut/pgut.o pgut/pgut.c
 
In file included from pgut/pgut.c:10:0:
/usr/include/postgresql/postgres_fe.h:27:32: fatal error: common/fe_memutils.h: No such file or directory

This can be fixed by moving -I/usr/include/postgresql past the server
includes, but then there's other issues:

$ gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -pie -Wall
-Wmissing-prototypes-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing
-fwrapv-fexcess-precision=standard -g -DREPACK_VERSION=1.2.1 -I. -I. -I/usr/include/postgresql/9.1/server
-I/usr/include/postgresql/internal-I/usr/include/postgresql -D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ=0 -D_GNU_SOURCE
-I/usr/include/libxml2 -I/usr/include/tcl8.5  -c -o pgut/pgut.o pgut/pgut.c
 
In file included from pgut/pgut.h:23:0,                from pgut/pgut.c:17:
/usr/include/postgresql/libpq-fe.h:547:1: error: unknown type name 'pg_int64'
/usr/include/postgresql/libpq-fe.h:547:50: error: unknown type name 'pg_int64'
/usr/include/postgresql/libpq-fe.h:551:1: error: unknown type name 'pg_int64'
/usr/include/postgresql/libpq-fe.h:553:48: error: unknown type name 'pg_int64'

This seems to be another instance of the "(includedir_internal)
headers are not self-contained" problem, see
http://www.postgresql.org/message-id/20140426122548.GA7249@msgid.df7cb.de

Possibly we need to move some files in libpq-dev to/from
postgresql-server-dev-*, though I believe the Debian packages are now
just replicating whatever header layout the PostgreSQL makefiles
construct on install. (Namely server -> /usr/include/postgresql/9.4/server,
Rest -> /usr/include/postgresql/)

I haven't tried to check all include paths with various combinations
of libpq-dev and postgresql-server-dev-one-or-the-other-version
installed, though that would be an interesting exercise. Any
volunteers?

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Next
From: Robert Haas
Date:
Subject: Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations