Thread: pg_config problems on PG9.3/Centos?
Hi. I'm trying to build the table_log module for Postgres 9.3, and am wondering if there is an issue with pg_config. I installed Postgres on a fresh CentOS 6.5 with the pgdg packages:
--
yum list installed postgres*
Installed Packages
postgresql93.x86_64 9.3.2-1PGDG.rhel6 @pgdg93
postgresql93-contrib.x86_64 9.3.2-1PGDG.rhel6 @pgdg93
postgresql93-devel.x86_64 9.3.2-1PGDG.rhel6 @pgdg93
postgresql93-libs.x86_64 9.3.2-1PGDG.rhel6 @pgdg93
postgresql93-pltcl.x86_64 9.3.2-1PGDG.rhel6 @pgdg93
postgresql93-server.x86_64 9.3.2-1PGDG.rhel6 @pgdg93
I'm using this makefile, which has the path to pg_config hard-coded in it, with "make USE_PGXS=1":
MODULES = table_log
DATA_built = table_log.sql
DOCS = README.table_log
ifdef USE_PGXS
PGXS := $(shell /usr/pgsql-9.3/bin/pg_config --pgxs)
include $(PGXS)
else
subdir = contrib/table_log
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif
This works for me on a similar pg 9.2/Centos 6 setup, but fails on 9.3:
table_log.c:14:22: error: postgres.h: No such file or directory
table_log.c:15:18: error: fmgr.h: No such file or directory
table_log.c:16:71: error: executor/spi.h: No such file or directory
table_log.c:17:53: error: commands/trigger.h: No such file or directory
table_log.c:18:65: error: mb/pg_wchar.h: No such file or directory
table_log.c:21:23: error: miscadmin.h: No such file or directory
table_log.c:22:30: error: utils/formatting.h: No such file or directory
table_log.c:23:28: error: utils/builtins.h: No such file or directory
table_log.c:24:29: error: utils/lsyscache.h: No such file or directory
table_log.c:25:21: error: funcapi.h: No such file or directory
When I look the output of pg_config, and especially compared to my 9.2 output, it seems suspiciously lacking some 9.3 paths:
[root@new-agency table_log-0.4.4]# pg_config | more
BINDIR = /usr/bin
DOCDIR = /usr/share/doc/pgsql
HTMLDIR = /usr/share/doc/pgsql
INCLUDEDIR = /usr/include
PKGINCLUDEDIR = /usr/include
INCLUDEDIR-SERVER = /usr/include/server
LIBDIR = /usr/lib
PKGLIBDIR = /usr/lib
LOCALEDIR = /usr/share/locale
MANDIR = /usr/share/man
SHAREDIR = /usr/share
SYSCONFDIR = /etc/sysconfig/pgsql
PGXS = /usr/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--disable-rpath' '--prefix=/usr/pgsql-9.3' '--includedir=/usr/pgsql-9.3/include' '--mandir=/
usr/pgsql-9.3/share/man' '--datadir=/usr/pgsql-9.3/share' '--with-perl' '--with-python' '--with-tcl' '--w
ith-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-krb5' '--with-gssapi' '--with-includes=/u
sr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--with-ossp-uuid' '--with-libxml' '--with-libxs
lt' '--with-ldap' '--with-system-tzdata=/usr/share/zoneinfo' '--sysconfdir=/etc/sysconfig/pgsql' '--docdi
r=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --par
am=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et'
CC = gcc
CPPFLAGS = -I/usr/include/et -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include
CFLAGS = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-siz
e=4 -m64 -mtune=generic -I/usr/include/et -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-
statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
CFLAGS_SL = -fpic
LDFLAGS = -L../../../src/common -L/usr/lib64 -Wl,--as-needed
LDFLAGS_EX =
LDFLAGS_SL =
LIBS = -lpgport -lpgcommon -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -
lm
VERSION = PostgreSQL 9.3.2
My 9.2 pg_config:
[root@hosting table_log-0.4.4]# pg_config
BINDIR = /usr/pgsql-9.2/bin
DOCDIR = /usr/share/doc/pgsql
HTMLDIR = /usr/share/doc/pgsql
INCLUDEDIR = /usr/pgsql-9.2/include
PKGINCLUDEDIR = /usr/pgsql-9.2/include
INCLUDEDIR-SERVER = /usr/pgsql-9.2/include/server
LIBDIR = /usr/pgsql-9.2/lib
PKGLIBDIR = /usr/pgsql-9.2/lib
LOCALEDIR = /usr/pgsql-9.2/share/locale
MANDIR = /usr/pgsql-9.2/share/man
SHAREDIR = /usr/pgsql-9.2/share
SYSCONFDIR = /etc/sysconfig/pgsql
PGXS = /usr/pgsql-9.2/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--disable-rpath' '--prefix=/usr/pgsql-9.2' '--includedir=/usr/pgsql-9.2/include' '--mandir=/usr/pgsql-9.2/share/man' '--datadir=/usr/pgsql-9.2/share' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-krb5' '--with-gssapi' '--with-includes=/usr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--with-ossp-uuid' '--with-libxml' '--with-libxslt' '--with-ldap' '--with-system-tzdata=/usr/share/zoneinfo' '--sysconfdir=/etc/sysconfig/pgsql' '--docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et'
CC = gcc
CPPFLAGS = -I/usr/include/et -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include
CFLAGS = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
CFLAGS_SL = -fpic
LDFLAGS = -L/usr/lib64 -Wl,--as-needed
LDFLAGS_EX =
LDFLAGS_SL =
LIBS = -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm
VERSION = PostgreSQL 9.2.6
I could probably hack around this, but I'm wondering if I'm either missing some easy step, or if there's a problem with the 9.3 packages. Thanks in advance.
Ken
AGENCY Software
A data system that puts you in control
100% Free Software
(253) 245-3801
learn more about AGENCY or
follow the discussion.
Ken Tanzer <ken.tanzer@gmail.com> writes: > When I look the output of pg_config, and especially compared to my 9.2 > output, it seems suspiciously lacking some 9.3 paths: > [root@new-agency table_log-0.4.4]# pg_config | more > BINDIR = /usr/bin > DOCDIR = /usr/share/doc/pgsql > HTMLDIR = /usr/share/doc/pgsql > INCLUDEDIR = /usr/include > PKGINCLUDEDIR = /usr/include > INCLUDEDIR-SERVER = /usr/include/server > LIBDIR = /usr/lib > PKGLIBDIR = /usr/lib > LOCALEDIR = /usr/share/locale > MANDIR = /usr/share/man > SHAREDIR = /usr/share > SYSCONFDIR = /etc/sysconfig/pgsql Exactly where is root's path finding pg_config? IIRC, most of the paths shown here are actually computed relative to the location of the pg_config executable, so I could imagine getting this kind of result if you'd done something like symlinking pg_config into /usr/bin. I would've guessed that you were invoking a pg_config shipped with the regular Red Hat postgres packages, except for this: > CONFIGURE = '--disable-rpath' '--prefix=/usr/pgsql-9.3' > '--includedir=/usr/pgsql-9.3/include' '--mandir=/ > usr/pgsql-9.3/share/man' '--datadir=/usr/pgsql-9.3/share' '--with-perl' which seems to prove that the package was built with the correct options for PGDG's file placement. regards, tom lane
On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Exactly where is root's path finding pg_config?
IIRC, most of the paths shown here are actually computed relative to the
location of the pg_config executable, so I could imagine getting this
kind of result if you'd done something like symlinking pg_config into
/usr/bin.
Oddly, there was a pg_config in /usr/bin that was not a symlink and not owned by any package. I'm really puzzled as to how it got there, but I removed it, and symlinked the one from /usr/pgsql-9.3/bin. It puts out better information.
It also sounds like from your comment that symlinking to /usr/bin is frowned upon. What is the better way to deal with this?
So with the pg_config thing resolved, my make now get stuck on the error below. I found a BSD bug report with the same message from 9.2, although I was able to successfully compile for 9.2 previously. I'm wondering if anyone seems something obvious or simple that could be causing this or could be fixed. I know the table_log packages are kind of ancient, but they do the trick!
table_log.c: In function ‘table_log’:
table_log.c:134: warning: implicit declaration of function ‘RelationGetNamespace’
table_log.c:140: error: dereferencing pointer to incomplete type
table_log.c: In function ‘__table_log’:
table_log.c:301: error: dereferencing pointer to incomplete type
table_log.c:310: error: dereferencing pointer to incomplete type
table_log.c:312: error: dereferencing pointer to incomplete type
table_log.c:346: error: dereferencing pointer to incomplete type
table_log.c:354: error: dereferencing pointer to incomplete type
table_log.c:373: error: dereferencing pointer to incomplete type
table_log.c:381: error: dereferencing pointer to incomplete type
table_log.c: In function ‘table_log_restore_table’:
table_log.c:794: error: ‘timestamptz_out’ undeclared (first use in this function)
table_log.c:794: error: (Each undeclared identifier is reported only once
table_log.c:794: error: for each function it appears in.)
make: *** [table_log.o] Error 1
I would've guessed that you were invoking a pg_config shipped with the
regular Red Hat postgres packages, except for this:which seems to prove that the package was built with the correct
> CONFIGURE = '--disable-rpath' '--prefix=/usr/pgsql-9.3'
> '--includedir=/usr/pgsql-9.3/include' '--mandir=/
> usr/pgsql-9.3/share/man' '--datadir=/usr/pgsql-9.3/share' '--with-perl'
options for PGDG's file placement.
regards, tom lane
I'm _pretty_ sure I didn't even install the CentOs postgres packages. OTOH, where that /usr/bin/pg_config came from is a complete mystery!
Cheers,
Ken
--
AGENCY Software
A data system that puts you in control
100% Free Software
(253) 245-3801
learn more about AGENCY or
follow the discussion.
Ken Tanzer <ken.tanzer@gmail.com> writes: > On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> IIRC, most of the paths shown here are actually computed relative to the >> location of the pg_config executable, so I could imagine getting this >> kind of result if you'd done something like symlinking pg_config into >> /usr/bin. > Oddly, there was a pg_config in /usr/bin that was not a symlink and not > owned by any package. I'm really puzzled as to how it got there, but I > removed it, and symlinked the one from /usr/pgsql-9.3/bin. It puts out > better information. OK. > It also sounds like from your comment that symlinking to /usr/bin is > frowned upon. What is the better way to deal with this? I had forgotten the details, but if pg_config is giving you the right answers then it must know about following the symlink. So nevermind that worry. > So with the pg_config thing resolved, my make now get stuck on the error > below. I found a BSD bug report with the same message from 9.2, although I > was able to successfully compile for 9.2 previously. I'm wondering if > anyone seems something obvious or simple that could be causing this or > could be fixed. I know the table_log packages are kind of ancient, but > they do the trick! > table_log.c: In function �table_log�: > table_log.c:134: warning: implicit declaration of function > �RelationGetNamespace� > table_log.c:140: error: dereferencing pointer to incomplete type > table_log.c: In function �__table_log�: > table_log.c:301: error: dereferencing pointer to incomplete type > table_log.c:310: error: dereferencing pointer to incomplete type > table_log.c:312: error: dereferencing pointer to incomplete type > table_log.c:346: error: dereferencing pointer to incomplete type > table_log.c:354: error: dereferencing pointer to incomplete type > table_log.c:373: error: dereferencing pointer to incomplete type > table_log.c:381: error: dereferencing pointer to incomplete type > table_log.c: In function �table_log_restore_table�: > table_log.c:794: error: �timestamptz_out� undeclared (first use in this > function) > table_log.c:794: error: (Each undeclared identifier is reported only once > table_log.c:794: error: for each function it appears in.) > make: *** [table_log.o] Error 1 It looks like the code is missing some #include's. You at least need utils/rel.h for RelationGetNamespace and utils/timestamp.h for timestamptz_out. Can't tell from this what typedef is missing but it's possible adding those will fix it; if not you'll need to look at the complained-of lines and then grep the Postgres include files to see which one provides it. We occasionally add or remove header inclusions of other headers, which probably explains why this code compiled on older versions but not 9.3. regards, tom lane
On 01/21/2014 01:18 PM, Ken Tanzer wrote: > On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us > Oddly, there was a pg_config in /usr/bin that was not a symlink and not > owned by any package. I'm really puzzled as to how it got there, but I > removed it, and symlinked the one from /usr/pgsql-9.3/bin. It puts out > better information. > > It also sounds like from your comment that symlinking to /usr/bin is > frowned upon. What is the better way to deal with this? > > So with the pg_config thing resolved, my make now get stuck on the error > below. I found a BSD bug report with the same message from 9.2, > although I was able to successfully compile for 9.2 previously. I'm > wondering if anyone seems something obvious or simple that could be > causing this or could be fixed. I know the table_log packages are kind > of ancient, but they do the trick! > > table_log.c: In function ‘table_log’: > table_log.c:134: warning: implicit declaration of function > ‘RelationGetNamespace’ > table_log.c:140: error: dereferencing pointer to incomplete type > table_log.c: In function ‘__table_log’: > table_log.c:301: error: dereferencing pointer to incomplete type > table_log.c:310: error: dereferencing pointer to incomplete type > table_log.c:312: error: dereferencing pointer to incomplete type > table_log.c:346: error: dereferencing pointer to incomplete type > table_log.c:354: error: dereferencing pointer to incomplete type > table_log.c:373: error: dereferencing pointer to incomplete type > table_log.c:381: error: dereferencing pointer to incomplete type > table_log.c: In function ‘table_log_restore_table’: > table_log.c:794: error: ‘timestamptz_out’ undeclared (first use in this > function) > table_log.c:794: error: (Each undeclared identifier is reported only once > table_log.c:794: error: for each function it appears in.) > make: *** [table_log.o] Error 1 > I saw a similiar thing on the -odbc list where someone was using PGXS to build something. It seemed AFAICT the build was not picking up timestamp.h from the Postgres includes. This is where timestamptz_out is found. I suggested they manually include it in the *.c file. I never heard back so I assumed that worked, though I can not be sure. -- Adrian Klaver adrian.klaver@gmail.com
On Tue, Jan 21, 2014 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ken Tanzer <ken.tanzer@gmail.com> writes:
> On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:>> IIRC, most of the paths shown here are actually computed relative to theOK.
>> location of the pg_config executable, so I could imagine getting this
>> kind of result if you'd done something like symlinking pg_config into
>> /usr/bin.
> Oddly, there was a pg_config in /usr/bin that was not a symlink and not
> owned by any package. I'm really puzzled as to how it got there, but I
> removed it, and symlinked the one from /usr/pgsql-9.3/bin. It puts out
> better information.I had forgotten the details, but if pg_config is giving you the right
> It also sounds like from your comment that symlinking to /usr/bin is
> frowned upon. What is the better way to deal with this?
answers then it must know about following the symlink. So nevermind
that worry.
I'm happy not to mind, but it seems like everything else just works "out of the box," so I wonder why not this little piece?
> So with the pg_config thing resolved, my make now get stuck on the errorIt looks like the code is missing some #include's. You at least
I'> below. I found a BSD bug report with the same message from 9.2, although I
> was able to successfully compile for 9.2 previously. I'm wondering if
> anyone seems something obvious or simple that could be causing this or
> could be fixed. I know the table_log packages are kind of ancient, but
> they do the trick!
> table_log.c: In function ‘table_log’:
> table_log.c:134: warning: implicit declaration of function
> ‘RelationGetNamespace’
> table_log.c:140: error: dereferencing pointer to incomplete type
> table_log.c: In function ‘__table_log’:
> table_log.c:301: error: dereferencing pointer to incomplete type
> table_log.c:310: error: dereferencing pointer to incomplete type
> table_log.c:312: error: dereferencing pointer to incomplete type
> table_log.c:346: error: dereferencing pointer to incomplete type
> table_log.c:354: error: dereferencing pointer to incomplete type
> table_log.c:373: error: dereferencing pointer to incomplete type
> table_log.c:381: error: dereferencing pointer to incomplete type
> table_log.c: In function ‘table_log_restore_table’:
> table_log.c:794: error: ‘timestamptz_out’ undeclared (first use in this
> function)
> table_log.c:794: error: (Each undeclared identifier is reported only once
> table_log.c:794: error: for each function it appears in.)
> make: *** [table_log.o] Error 1
need utils/rel.h for RelationGetNamespace and utils/timestamp.h
for timestamptz_out. Can't tell from this what typedef is missing
but it's possible adding those will fix it; if not you'll need to
look at the complained-of lines and then grep the Postgres include
files to see which one provides it.
We occasionally add or remove header inclusions of other headers,
which probably explains why this code compiled on older versions
but not 9.3.
regards, tom lane
Adding those two includes did the trick--thanks!
Ken
--
AGENCY Software
A data system that puts you in control
100% Free Software
(253) 245-3801
learn more about AGENCY or
follow the discussion.
Ken Tanzer <ken.tanzer@gmail.com> writes: > On Tue, Jan 21, 2014 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Ken Tanzer <ken.tanzer@gmail.com> writes: >>> It also sounds like from your comment that symlinking to /usr/bin is >>> frowned upon. What is the better way to deal with this? >> I had forgotten the details, but if pg_config is giving you the right >> answers then it must know about following the symlink. So nevermind >> that worry. > I'm happy not to mind, but it seems like everything else just works "out of > the box," so I wonder why not this little piece? Nah, it works fine. I was just jumping to a conclusion based on insufficient information. regards, tom lane
Hi, On Tue, 2014-01-21 at 13:18 -0800, Ken Tanzer wrote: > Oddly, there was a pg_config in /usr/bin that was not a symlink and > not owned by any package. I'm really puzzled as to how it got there, > but I removed it, and symlinked the one from /usr/pgsql-9.3/bin. It > puts out better information. Please don't do it. PGDG RPMs are designed for parallel installation (like 9.2 and 9.3 on the same machine), and then the pg_config in regular $PATH might be tricky. Anyway: > I know the table_log packages are kind of ancient, but they do the > trick! > > table_log.c: In function ‘table_log’: > table_log.c:134: warning: implicit declaration of function > ‘RelationGetNamespace’ <snip> table_log is not being maintained anymore -- you can use emaj. It is already available in the same RPM repo: http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/repoview/emaj.html Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
On Tue, Jan 21, 2014 at 3:16 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
Thanks, and Cheers,
Hi,Please don't do it. PGDG RPMs are designed for parallel installation
On Tue, 2014-01-21 at 13:18 -0800, Ken Tanzer wrote:
> Oddly, there was a pg_config in /usr/bin that was not a symlink and
> not owned by any package. I'm really puzzled as to how it got there,
> but I removed it, and symlinked the one from /usr/pgsql-9.3/bin. It
> puts out better information.
(like 9.2 and 9.3 on the same machine), and then the pg_config in
regular $PATH might be tricky.
It didn't seem like a great idea to me either, but what's the better alternative? Without the symlink I get lots of errors:
make USE_PGXS=1
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
make: pg_config: Command not found
Anyway:<snip>
> I know the table_log packages are kind of ancient, but they do the
> trick!
>
> table_log.c: In function ‘table_log’:
> table_log.c:134: warning: implicit declaration of function
> ‘RelationGetNamespace’
table_log is not being maintained anymore -- you can use emaj. It is
already available in the same RPM repo:
http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/repoview/emaj.html
I'm not opposed to newer and better, but at first glance this sounds like headache for no gain. Currently table_log is doing the trick for me (I only use it for tracking revisions, not rollbacks), and I have several organizations running with their revision history in table_log format. Is the table format by any chance the same, and/or is there an easy way to move from one to the other?
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Ken
--
AGENCY Software
A data system that puts you in control
100% Free Software
(253) 245-3801
learn more about AGENCY or
follow the discussion.
Ken Tanzer <ken.tanzer@gmail.com> writes: > On Tue, Jan 21, 2014 at 3:16 PM, Devrim G�ND�Z <devrim@gunduz.org> wrote: >> Please don't do it. PGDG RPMs are designed for parallel installation >> (like 9.2 and 9.3 on the same machine), and then the pg_config in >> regular $PATH might be tricky. > It didn't seem like a great idea to me either, but what's the better > alternative? Without the symlink I get lots of errors: You should arrange for the appropriate pg_config to be in your PATH when you're using pgxs. Copying (or symlinking) pg_config into /usr/bin is a pretty horrible substitute for a temporary PATH change. regards, tom lane
Hi, On Tue, 2014-01-21 at 18:00 -0800, Ken Tanzer wrote: > It didn't seem like a great idea to me either, but what's the better > alternative? Without the symlink I get lots of errors: > > make USE_PGXS=1 > make: pg_config: Command not found Sometimes exporting PG_CONFIG does the trick. Alternatively, while building the RPMs, we add a patch to makefiles like this: http://svn.pgrpms.org/repo/rpm/redhat/9.3/ip4r/F-20/Makefile-pgxs.patch Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
On Tue, Jan 21, 2014 at 11:49 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
Hi,Sometimes exporting PG_CONFIG does the trick. Alternatively, while
On Tue, 2014-01-21 at 18:00 -0800, Ken Tanzer wrote:
> It didn't seem like a great idea to me either, but what's the better
> alternative? Without the symlink I get lots of errors:
>
> make USE_PGXS=1
> make: pg_config: Command not found
building the RPMs, we add a patch to makefiles like this:
http://svn.pgrpms.org/repo/rpm/redhat/9.3/ip4r/F-20/Makefile-pgxs.patch
Thanks, that works. I'm inferring that PG_CONFIG is a variable that needs to be set? This seemingly similar piece of makefile doesn't work:
ifdef USE_PGXS
PGXS := $(shell /usr/pgsql-9.3/bin/pg_config --pgxs)
include $(PGXS)
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Cheers,
Ken
AGENCY Software
A Free Software data system
By and for non-profits
(253) 245-3801
learn more about AGENCY or
follow the discussion.