configure fails to find libpq
Hi, I am having trouble enabling pgsql support with the configure script and I will almost (boldly!) claim there might be a problem we the configure script. Autoconf and friends is however close to black magic and voodoo so I will try to assert my viewpoint and hopefully someone can point out my level of cluelessness :-) I am able to compile and run Freeswitch 1.2.8 (without core-pgsql), PostgreSQL 9.2.4 and OpenResty 1.2.8.5 (with libpq!). Openresty was configured with: ./configure --with-luajit --with-http_iconv_module --with-http_postgres_module --with-libpq=/usr/pgsql-9.2 Hence I know that I have a recent and working libpq. From previous mails on this list I can see that is the typical response to this issue is to install postgresql92-devel which I have already done. However freeswitch configure fails: $ ./configure --enable-core-pgsql-support <snip> checking for odbc header in /usr/include... found checking for SQLDisconnect in -lodbc... yes checking whether to include odbc... yes checking for SQLDisconnect in -lodbc... (cached) yes checking for pg_config... /usr/pgsql-9.2/bin/pg_config checking for PostgreSQL libraries... checking for PQgetvalue in -lpq... no configure: error: no usable libpq; please install PostgreSQL devel package or equivalent The part of configure which fails is: { $as_echo "$as_me:$LINENO: checking for PQgetvalue in -lpq" >&5 $as_echo_n "checking for PQgetvalue in -lpq... " >&6; } if test "${ac_cv_lib_pq_PQgetvalue+set}" = set; then $as_echo_n "(cached) " >&6 else ac_check_lib_save_LIBS=$LIBS LIBS="-lpq $LIBS" I do simply not understand what "${ac_cv_lib_pq_PQgetvalue+set}" actually is doing and it becomes a dark art for me. If I remove the "if" clause I assume things would simply work (as LIBS should be correct)! My initial thought was to try to make an addition to configure to support the following options: --with-pgsql-lib=dir --with-pqsql-include=dir My OCD does however not like that I do not understand the test performed today. To blindly add those options would be too hackish (and stoopid). Can anyone explain what happens in the configure script? I would rather spend some time making sure configure works perfectly rather than tweaking my environment to match the expectations of the script. Kind Regards, Claus Andersen Additional info: Freeswitch 1.2.8 with PostgreSQL 9.2.4 uname -m = x86_64 uname -r = 2.6.32-358.6.1.el6.x86_64 uname -s = Linux uname -v = #1 SMP Tue Apr 23 19:29:00 UTC 2013 $ grep PQgetvalue /usr/pgsql-9.2/include/libpq-fe.h extern char *PQgetvalue(const PGresult *res, int tup_num, int field_num); $ pg_config (excerpt) INCLUDEDIR = /usr/pgsql-9.2/include LIBDIR = /usr/pgsql-9.2/lib LDFLAGS = -L/usr/lib64 -Wl,--as-needed LIBS = -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm VERSION = PostgreSQL 9.2.4 $ tail config.log #define HAVE_ODBC 1 #define HAVE_LIBODBC 1 #define SWITCH_HAVE_PGSQL 1 #define POSTGRESQL_VERSION "9.2.4" #define POSTGRESQL_MAJOR_VERSION 9 #define POSTGRESQL_MINOR_VERSION 2 #define POSTGRESQL_PATCH_VERSION 4 configure: exit 1 $ rpm -ql postgresql92-devel | grep libpq /usr/pgsql-9.2/include/internal/libpq /usr/pgsql-9.2/include/internal/libpq-int.h /usr/pgsql-9.2/include/internal/libpq/pqcomm.h /usr/pgsql-9.2/include/libpq /usr/pgsql-9.2/include/libpq-events.h /usr/pgsql-9.2/include/libpq-fe.h /usr/pgsql-9.2/include/libpq/libpq-fs.h /usr/pgsql-9.2/include/server/libpq /usr/pgsql-9.2/include/server/libpq/auth.h /usr/pgsql-9.2/include/server/libpq/be-fsstubs.h /usr/pgsql-9.2/include/server/libpq/crypt.h /usr/pgsql-9.2/include/server/libpq/hba.h /usr/pgsql-9.2/include/server/libpq/ip.h /usr/pgsql-9.2/include/server/libpq/libpq-be.h /usr/pgsql-9.2/include/server/libpq/libpq-fs.h /usr/pgsql-9.2/include/server/libpq/libpq.h /usr/pgsql-9.2/include/server/libpq/md5.h /usr/pgsql-9.2/include/server/libpq/pqcomm.h /usr/pgsql-9.2/include/server/libpq/pqformat.h /usr/pgsql-9.2/include/server/libpq/pqsignal.h /usr/pgsql-9.2/lib/libpq.a /usr/pgsql-9.2/lib/libpq.so
Do you have libpq-dev installed? RPM systems probably call it something different (postgresql-devel?) libpq will just be the runtime libraries, you need the development files to compile software against the library. -Steve On 13 June 2013 12:34, Claus Andersen <clan@wheel.dk> wrote:
Hi,
I am having trouble enabling pgsql support with the configure script and I will almost (boldly!) claim there might be a problem we the configure script. Autoconf and friends is however close to black magic and voodoo so I will try to assert my viewpoint and hopefully someone can point out my level of cluelessness :-)
I am able to compile and run Freeswitch 1.2.8 (without core-pgsql), PostgreSQL 9.2.4 and OpenResty 1.2.8.5 (with libpq!).
Openresty was configured with: ./configure --with-luajit --with-http_iconv_module --with-http_postgres_module --with-libpq=/usr/pgsql-9.2
Hence I know that I have a recent and working libpq. From previous mails on this list I can see that is the typical response to this issue is to install postgresql92-devel which I have already done.
However freeswitch configure fails:
$ ./configure --enable-core-pgsql-support <snip> checking for odbc header in /usr/include... found checking for SQLDisconnect in -lodbc... yes checking whether to include odbc... yes checking for SQLDisconnect in -lodbc... (cached) yes checking for pg_config... /usr/pgsql-9.2/bin/pg_config checking for PostgreSQL libraries... checking for PQgetvalue in -lpq... no configure: error: no usable libpq; please install PostgreSQL devel package or equivalent
The part of configure which fails is:
{ $as_echo "$as_me:$LINENO: checking for PQgetvalue in -lpq" >&5 $as_echo_n "checking for PQgetvalue in -lpq... " >&6; } if test "${ac_cv_lib_pq_PQgetvalue+set}" = set; then $as_echo_n "(cached) " >&6 else ac_check_lib_save_LIBS=$LIBS LIBS="-lpq $LIBS"
I do simply not understand what "${ac_cv_lib_pq_PQgetvalue+set}" actually is doing and it becomes a dark art for me. If I remove the "if" clause I assume things would simply work (as LIBS should be correct)!
My initial thought was to try to make an addition to configure to support the following options: --with-pgsql-lib=dir --with-pqsql-include=dir
My OCD does however not like that I do not understand the test performed today. To blindly add those options would be too hackish (and stoopid).
Can anyone explain what happens in the configure script? I would rather spend some time making sure configure works perfectly rather than tweaking my environment to match the expectations of the script.
Kind Regards, Claus Andersen
Additional info:
Freeswitch 1.2.8 with PostgreSQL 9.2.4
uname -m = x86_64 uname -r = 2.6.32-358.6.1.el6.x86_64 uname -s = Linux uname -v = #1 SMP Tue Apr 23 19:29:00 UTC 2013
$ grep PQgetvalue /usr/pgsql-9.2/include/libpq-fe.h extern char *PQgetvalue(const PGresult *res, int tup_num, int field_num);
$ pg_config (excerpt) INCLUDEDIR = /usr/pgsql-9.2/include LIBDIR = /usr/pgsql-9.2/lib LDFLAGS = -L/usr/lib64 -Wl,--as-needed LIBS = -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm VERSION = PostgreSQL 9.2.4
$ tail config.log #define HAVE_ODBC 1 #define HAVE_LIBODBC 1 #define SWITCH_HAVE_PGSQL 1 #define POSTGRESQL_VERSION "9.2.4" #define POSTGRESQL_MAJOR_VERSION 9 #define POSTGRESQL_MINOR_VERSION 2 #define POSTGRESQL_PATCH_VERSION 4
configure: exit 1
$ rpm -ql postgresql92-devel | grep libpq /usr/pgsql-9.2/include/internal/libpq /usr/pgsql-9.2/include/internal/libpq-int.h /usr/pgsql-9.2/include/internal/libpq/pqcomm.h /usr/pgsql-9.2/include/libpq /usr/pgsql-9.2/include/libpq-events.h /usr/pgsql-9.2/include/libpq-fe.h /usr/pgsql-9.2/include/libpq/libpq-fs.h /usr/pgsql-9.2/include/server/libpq /usr/pgsql-9.2/include/server/libpq/auth.h /usr/pgsql-9.2/include/server/libpq/be-fsstubs.h /usr/pgsql-9.2/include/server/libpq/crypt.h /usr/pgsql-9.2/include/server/libpq/hba.h /usr/pgsql-9.2/include/server/libpq/ip.h /usr/pgsql-9.2/include/server/libpq/libpq-be.h /usr/pgsql-9.2/include/server/libpq/libpq-fs.h /usr/pgsql-9.2/include/server/libpq/libpq.h /usr/pgsql-9.2/include/server/libpq/md5.h /usr/pgsql-9.2/include/server/libpq/pqcomm.h /usr/pgsql-9.2/include/server/libpq/pqformat.h /usr/pgsql-9.2/include/server/libpq/pqsignal.h /usr/pgsql-9.2/lib/libpq.a /usr/pgsql-9.2/lib/libpq.so
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, 13 Jun 2013, Steven Ayre wrote:
Do you have libpq-dev installed? RPM systems probably call it something different (postgresql-devel?) libpq will just be the runtime libraries, you need the development files to compile software against the library.
Hi, Uhm? Apart from what I have already listed? As I wrote I have already built other projects against this library. Am I missing something obvious? postgresql92-devel $ rpm -ql postgresql92-devel | grep libpq /usr/pgsql-9.2/include/internal/libpq /usr/pgsql-9.2/include/internal/libpq-int.h /usr/pgsql-9.2/include/internal/libpq/pqcomm.h /usr/pgsql-9.2/include/libpq /usr/pgsql-9.2/include/libpq-events.h /usr/pgsql-9.2/include/libpq-fe.h /usr/pgsql-9.2/include/libpq/libpq-fs.h /usr/pgsql-9.2/include/server/libpq /usr/pgsql-9.2/include/server/libpq/auth.h /usr/pgsql-9.2/include/server/libpq/be-fsstubs.h /usr/pgsql-9.2/include/server/libpq/crypt.h /usr/pgsql-9.2/include/server/libpq/hba.h /usr/pgsql-9.2/include/server/libpq/ip.h /usr/pgsql-9.2/include/server/libpq/libpq-be.h /usr/pgsql-9.2/include/server/libpq/libpq-fs.h /usr/pgsql-9.2/include/server/libpq/libpq.h /usr/pgsql-9.2/include/server/libpq/md5.h /usr/pgsql-9.2/include/server/libpq/pqcomm.h /usr/pgsql-9.2/include/server/libpq/pqformat.h /usr/pgsql-9.2/include/server/libpq/pqsignal.h /usr/pgsql-9.2/lib/libpq.a /usr/pgsql-9.2/lib/libpq.so Kind Regards, Claus Andersen
Apologies - I missed you saying that part. Try checking config.log to see if there were any unusual errors during that test -Steve On Thursday, June 13, 2013, Claus Andersen wrote:
On Thu, 13 Jun 2013, Steven Ayre wrote:
Do you have libpq-dev installed? RPM systems probably call it something
different (postgresql-devel?) libpq will just be the runtime libraries, you need the development files to compile software against the library.
Hi,
Uhm? Apart from what I have already listed? As I wrote I have already built other projects against this library. Am I missing something obvious?
postgresql92-devel
$ rpm -ql postgresql92-devel | grep libpq /usr/pgsql-9.2/include/**internal/libpq /usr/pgsql-9.2/include/**internal/libpq-int.h /usr/pgsql-9.2/include/**internal/libpq/pqcomm.h /usr/pgsql-9.2/include/libpq /usr/pgsql-9.2/include/libpq-**events.h /usr/pgsql-9.2/include/libpq-**fe.h /usr/pgsql-9.2/include/libpq/**libpq-fs.h /usr/pgsql-9.2/include/server/**libpq /usr/pgsql-9.2/include/server/**libpq/auth.h /usr/pgsql-9.2/include/server/**libpq/be-fsstubs.h /usr/pgsql-9.2/include/server/**libpq/crypt.h /usr/pgsql-9.2/include/server/**libpq/hba.h /usr/pgsql-9.2/include/server/**libpq/ip.h /usr/pgsql-9.2/include/server/**libpq/libpq-be.h /usr/pgsql-9.2/include/server/**libpq/libpq-fs.h /usr/pgsql-9.2/include/server/**libpq/libpq.h /usr/pgsql-9.2/include/server/**libpq/md5.h /usr/pgsql-9.2/include/server/**libpq/pqcomm.h /usr/pgsql-9.2/include/server/**libpq/pqformat.h /usr/pgsql-9.2/include/server/**libpq/pqsignal.h /usr/pgsql-9.2/lib/libpq.a /usr/pgsql-9.2/lib/libpq.so
Kind Regards, Claus Andersen
To answer your question of what the test is doing, it'll take the required flags/libs from pg_config (which it looks like it found) and then try compiling a tiny program linking to it to check if the library exists and when testing functions if that function is exported by that version of the library. Any compile error means 'no'. That ac_ variable is checking if its 'set' which'd mean the test passed. Config.log will show all the tests being run and any error output for them. -Steve On Thursday, June 13, 2013, Claus Andersen wrote:
On Thu, 13 Jun 2013, Steven Ayre wrote:
Do you have libpq-dev installed? RPM systems probably call it something
different (postgresql-devel?) libpq will just be the runtime libraries, you need the development files to compile software against the library.
Hi,
Uhm? Apart from what I have already listed? As I wrote I have already built other projects against this library. Am I missing something obvious?
postgresql92-devel
$ rpm -ql postgresql92-devel | grep libpq /usr/pgsql-9.2/include/**internal/libpq /usr/pgsql-9.2/include/**internal/libpq-int.h /usr/pgsql-9.2/include/**internal/libpq/pqcomm.h /usr/pgsql-9.2/include/libpq /usr/pgsql-9.2/include/libpq-**events.h /usr/pgsql-9.2/include/libpq-**fe.h /usr/pgsql-9.2/include/libpq/**libpq-fs.h /usr/pgsql-9.2/include/server/**libpq /usr/pgsql-9.2/include/server/**libpq/auth.h /usr/pgsql-9.2/include/server/**libpq/be-fsstubs.h /usr/pgsql-9.2/include/server/**libpq/crypt.h /usr/pgsql-9.2/include/server/**libpq/hba.h /usr/pgsql-9.2/include/server/**libpq/ip.h /usr/pgsql-9.2/include/server/**libpq/libpq-be.h /usr/pgsql-9.2/include/server/**libpq/libpq-fs.h /usr/pgsql-9.2/include/server/**libpq/libpq.h /usr/pgsql-9.2/include/server/**libpq/md5.h /usr/pgsql-9.2/include/server/**libpq/pqcomm.h /usr/pgsql-9.2/include/server/**libpq/pqformat.h /usr/pgsql-9.2/include/server/**libpq/pqsignal.h /usr/pgsql-9.2/lib/libpq.a /usr/pgsql-9.2/lib/libpq.so
Kind Regards, Claus Andersen
On Thu, 13 Jun 2013, Steven Ayre wrote:
To answer your question of what the test is doing, it'll take the required flags/libs from pg_config (which it looks like it found) and then try compiling a tiny program linking to it to check if the library exists and when testing functions if that function is exported by that version of the library. Any compile error means 'no'. That ac_ variable is checking if its 'set' which'd mean the test passed. Config.log will show all the tests being run and any error output for them. -Steve
Thank you very much. Most helpful! I had only tail'ed config.log and further up I found: configure:19550: checking for PostgreSQL libraries configure:19584: checking for PQgetvalue in -lpq configure:19619: gcc -o conftest -g -O2 conftest.c -lpq -lodbc >&5 /usr/bin/ld: cannot find -lpq collect2: ld returned 1 exit status configure:19626: $? = 1 So the linker is not able to find and include the library. The empty spaces after -O2 and -lpq might indicate that some empty variables might have been inserted.
From configure I know that we can find pg_config:
checking for pg_config... /usr/pgsql-9.2/bin/pg_config checking for PostgreSQL libraries... checking for PQgetvalue in -lpq... no configure: error: no usable libpq; please install PostgreSQL devel package or equivalent And from the shell I know I get the proper path: $ pg_config --libdir /usr/pgsql-9.2/lib And from the configure script it looks like the correct parameter is used: POSTGRESQL_LDFLAGS="`$PG_CONFIG --ldflags` -L`$PG_CONFIG --libdir` -lpq" It looks like these flags are not passed to gcc/ld when linking conftest.c My conclusion is then that pg_config is found and the correct options and path are extracted but they are not used (ignored?) during testing. Or if they should be used - something even more serious is wrong. If that conclusion is correct I will file a Jira. The fix should be trivial for people in the know. I cannot determine whether the libdir should be added during the test. Or if pg_config should be ignored completely and replaced with a simple -with-pgsql-lib=dir. If I set LDFLAGS before I do a configure it works: $ LDFLAGS="${LDFLAGS} -L/usr/pgsql-9.2/lib" $ export LDFLAGS $./configure --enable-core-pgsql-support Configure then runs smoothly. Make does however fail but that is another issue I'll put in a seperate thread. With LDFLAGS set the relevant part of config.log now looks like this: configure:19604: checking for PQgetvalue in -lpq configure:19639: gcc -o conftest -g -O2 -L/usr/pgsql-9.2/lib conftest.c -lpq -lodbc >&5 configure:19646: $? = 0 configure:19667: result: yes Do you agree that this is a "proper" issue? Kind Regards, Claus Andersen
Looks to me like a bug in configure.in... 427: AC_CHECK_LIB([pq], [PQgetvalue],, AC_MSG_ERROR([no usable libpq; please install PostgreSQL devel package or equivalent])) Is the test whether it can link to libpq by checking if the PQgetvalue function is available, problem is it doesn't seem to use the pg_config values. So on a system like yours where libpq is installing to somewhere other than the main lib directories it's unable to detect the libary. File a Jira to track this if you haven't already done so. -Steve On 14 June 2013 15:35, Claus Andersen <clan@wheel.dk> wrote:
On Thu, 13 Jun 2013, Steven Ayre wrote:
To answer your question of what the test is doing, it'll take the
required flags/libs from pg_config (which it looks like it found) and then try compiling a tiny program linking to it to check if the library exists and when testing functions if that function is exported by that version of the library. Any compile error means 'no'. That ac_ variable is checking if its 'set' which'd mean the test passed. Config.log will show all the tests being run and any error output for them. -Steve
Thank you very much. Most helpful!
I had only tail'ed config.log and further up I found:
configure:19550: checking for PostgreSQL libraries configure:19584: checking for PQgetvalue in -lpq configure:19619: gcc -o conftest -g -O2 conftest.c -lpq -lodbc >&5 /usr/bin/ld: cannot find -lpq collect2: ld returned 1 exit status configure:19626: $? = 1
So the linker is not able to find and include the library. The empty spaces after -O2 and -lpq might indicate that some empty variables might have been inserted.
From configure I know that we can find pg_config:
checking for pg_config... /usr/pgsql-9.2/bin/pg_config checking for PostgreSQL libraries... checking for PQgetvalue in -lpq... no configure: error: no usable libpq; please install PostgreSQL devel package or equivalent
And from the shell I know I get the proper path: $ pg_config --libdir /usr/pgsql-9.2/lib
And from the configure script it looks like the correct parameter is used: POSTGRESQL_LDFLAGS="`$PG_**CONFIG --ldflags` -L`$PG_CONFIG --libdir` -lpq"
It looks like these flags are not passed to gcc/ld when linking conftest.c
My conclusion is then that pg_config is found and the correct options and path are extracted but they are not used (ignored?) during testing. Or if they should be used - something even more serious is wrong.
If that conclusion is correct I will file a Jira. The fix should be trivial for people in the know. I cannot determine whether the libdir should be added during the test. Or if pg_config should be ignored completely and replaced with a simple -with-pgsql-lib=dir.
If I set LDFLAGS before I do a configure it works: $ LDFLAGS="${LDFLAGS} -L/usr/pgsql-9.2/lib" $ export LDFLAGS $./configure --enable-core-pgsql-support
Configure then runs smoothly. Make does however fail but that is another issue I'll put in a seperate thread.
With LDFLAGS set the relevant part of config.log now looks like this: configure:19604: checking for PQgetvalue in -lpq configure:19639: gcc -o conftest -g -O2 -L/usr/pgsql-9.2/lib conftest.c -lpq -lodbc >&5 configure:19646: $? = 0 configure:19667: result: yes
Do you agree that this is a "proper" issue?
Kind Regards, Claus Andersen _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Adding this line immediately before AC_CHECK_LIB, bootstrap.sh again, and then try configure. LDFLAGS="$LDFLAGS `$PG_CONFIG --libdir`" It's a possible workaround rather than an actual fix (and an ugly one at that since it then keeps that lib directory for the rest of the script). One I haven't actually tested since libpq-dev on my system (Debian) installs to /usr/lib so doesn't have your issue. So let us know how you get on with it. If detected POSTGRESQL_LDFLAGS is already set containing the correct path so if that's what gets used by the build it might not be a problem past the configure stage. -Steve On 14 June 2013 16:58, Steven Ayre <steveayre@gmail.com> wrote:
Looks to me like a bug in configure.in...
427: AC_CHECK_LIB([pq], [PQgetvalue],, AC_MSG_ERROR([no usable libpq; please install PostgreSQL devel package or equivalent]))
Is the test whether it can link to libpq by checking if the PQgetvalue function is available, problem is it doesn't seem to use the pg_config values. So on a system like yours where libpq is installing to somewhere other than the main lib directories it's unable to detect the libary.
File a Jira to track this if you haven't already done so.
-Steve
On 14 June 2013 15:35, Claus Andersen <clan@wheel.dk> wrote:
On Thu, 13 Jun 2013, Steven Ayre wrote:
To answer your question of what the test is doing, it'll take the
required flags/libs from pg_config (which it looks like it found) and then try compiling a tiny program linking to it to check if the library exists and when testing functions if that function is exported by that version of the library. Any compile error means 'no'. That ac_ variable is checking if its 'set' which'd mean the test passed. Config.log will show all the tests being run and any error output for them. -Steve
Thank you very much. Most helpful!
I had only tail'ed config.log and further up I found:
configure:19550: checking for PostgreSQL libraries configure:19584: checking for PQgetvalue in -lpq configure:19619: gcc -o conftest -g -O2 conftest.c -lpq -lodbc >&5 /usr/bin/ld: cannot find -lpq collect2: ld returned 1 exit status configure:19626: $? = 1
So the linker is not able to find and include the library. The empty spaces after -O2 and -lpq might indicate that some empty variables might have been inserted.
From configure I know that we can find pg_config:
checking for pg_config... /usr/pgsql-9.2/bin/pg_config checking for PostgreSQL libraries... checking for PQgetvalue in -lpq... no configure: error: no usable libpq; please install PostgreSQL devel package or equivalent
And from the shell I know I get the proper path: $ pg_config --libdir /usr/pgsql-9.2/lib
And from the configure script it looks like the correct parameter is used: POSTGRESQL_LDFLAGS="`$PG_**CONFIG --ldflags` -L`$PG_CONFIG --libdir` -lpq"
It looks like these flags are not passed to gcc/ld when linking conftest.c
My conclusion is then that pg_config is found and the correct options and path are extracted but they are not used (ignored?) during testing. Or if they should be used - something even more serious is wrong.
If that conclusion is correct I will file a Jira. The fix should be trivial for people in the know. I cannot determine whether the libdir should be added during the test. Or if pg_config should be ignored completely and replaced with a simple -with-pgsql-lib=dir.
If I set LDFLAGS before I do a configure it works: $ LDFLAGS="${LDFLAGS} -L/usr/pgsql-9.2/lib" $ export LDFLAGS $./configure --enable-core-pgsql-support
Configure then runs smoothly. Make does however fail but that is another issue I'll put in a seperate thread.
With LDFLAGS set the relevant part of config.log now looks like this: configure:19604: checking for PQgetvalue in -lpq configure:19639: gcc -o conftest -g -O2 -L/usr/pgsql-9.2/lib conftest.c -lpq -lodbc >&5 configure:19646: $? = 0 configure:19667: result: yes
Do you agree that this is a "proper" issue?
Kind Regards, Claus Andersen _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Err, that should be LDFLAGS="$LDFLAGS -L`$PG_CONFIG --libdir`" On 14 June 2013 17:02, Steven Ayre <steveayre@gmail.com> wrote:
Adding this line immediately before AC_CHECK_LIB, bootstrap.sh again, and then try configure.
LDFLAGS="$LDFLAGS `$PG_CONFIG --libdir`"
It's a possible workaround rather than an actual fix (and an ugly one at that since it then keeps that lib directory for the rest of the script). One I haven't actually tested since libpq-dev on my system (Debian) installs to /usr/lib so doesn't have your issue. So let us know how you get on with it.
If detected POSTGRESQL_LDFLAGS is already set containing the correct path so if that's what gets used by the build it might not be a problem past the configure stage.
-Steve
On 14 June 2013 16:58, Steven Ayre <steveayre@gmail.com> wrote:
Looks to me like a bug in configure.in...
427: AC_CHECK_LIB([pq], [PQgetvalue],, AC_MSG_ERROR([no usable libpq; please install PostgreSQL devel package or equivalent]))
Is the test whether it can link to libpq by checking if the PQgetvalue function is available, problem is it doesn't seem to use the pg_config values. So on a system like yours where libpq is installing to somewhere other than the main lib directories it's unable to detect the libary.
File a Jira to track this if you haven't already done so.
-Steve
On 14 June 2013 15:35, Claus Andersen <clan@wheel.dk> wrote:
On Thu, 13 Jun 2013, Steven Ayre wrote:
To answer your question of what the test is doing, it'll take the
required flags/libs from pg_config (which it looks like it found) and then try compiling a tiny program linking to it to check if the library exists and when testing functions if that function is exported by that version of the library. Any compile error means 'no'. That ac_ variable is checking if its 'set' which'd mean the test passed. Config.log will show all the tests being run and any error output for them. -Steve
Thank you very much. Most helpful!
I had only tail'ed config.log and further up I found:
configure:19550: checking for PostgreSQL libraries configure:19584: checking for PQgetvalue in -lpq configure:19619: gcc -o conftest -g -O2 conftest.c -lpq -lodbc >&5 /usr/bin/ld: cannot find -lpq collect2: ld returned 1 exit status configure:19626: $? = 1
So the linker is not able to find and include the library. The empty spaces after -O2 and -lpq might indicate that some empty variables might have been inserted.
From configure I know that we can find pg_config:
checking for pg_config... /usr/pgsql-9.2/bin/pg_config checking for PostgreSQL libraries... checking for PQgetvalue in -lpq... no configure: error: no usable libpq; please install PostgreSQL devel package or equivalent
And from the shell I know I get the proper path: $ pg_config --libdir /usr/pgsql-9.2/lib
And from the configure script it looks like the correct parameter is used: POSTGRESQL_LDFLAGS="`$PG_**CONFIG --ldflags` -L`$PG_CONFIG --libdir` -lpq"
It looks like these flags are not passed to gcc/ld when linking conftest.c
My conclusion is then that pg_config is found and the correct options and path are extracted but they are not used (ignored?) during testing. Or if they should be used - something even more serious is wrong.
If that conclusion is correct I will file a Jira. The fix should be trivial for people in the know. I cannot determine whether the libdir should be added during the test. Or if pg_config should be ignored completely and replaced with a simple -with-pgsql-lib=dir.
If I set LDFLAGS before I do a configure it works: $ LDFLAGS="${LDFLAGS} -L/usr/pgsql-9.2/lib" $ export LDFLAGS $./configure --enable-core-pgsql-support
Configure then runs smoothly. Make does however fail but that is another issue I'll put in a seperate thread.
With LDFLAGS set the relevant part of config.log now looks like this: configure:19604: checking for PQgetvalue in -lpq configure:19639: gcc -o conftest -g -O2 -L/usr/pgsql-9.2/lib conftest.c -lpq -lodbc >&5 configure:19646: $? = 0 configure:19667: result: yes
Do you agree that this is a "proper" issue?
Kind Regards, Claus Andersen _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Fri, 14 Jun 2013, Steven Ayre wrote:
Adding this line immediately before AC_CHECK_LIB, bootstrap.sh again, and then try configure. LDFLAGS="$LDFLAGS `$PG_CONFIG --libdir`"
It's a possible workaround rather than an actual fix (and an ugly one at that since it then keeps that lib directory for the rest of the script). One I haven't actually tested since libpq-dev on my system (Debian) installs to /usr/lib so doesn't have your issue. So let us know how you get on with it.
If detected POSTGRESQL_LDFLAGS is already set containing the correct path so if that's what gets used by the build it might not be a problem past the configure stage.
I assume that the following has the same effect: $ LDFLAGS="${LDFLAGS} -L/usr/pgsql-9.2/lib" $ export LDFLAGS $./configure --enable-core-pgsql-support This fails during make and I have written a sperate mail to that effect. I will try your suggestion as well. Would the proper procedure be to file a new bug or should the make error be filed as a seperate (but related) bug? Kind Regards, Claus Andersen
On Fri, 14 Jun 2013, Steven Ayre wrote:
Looks to me like a bug in configure.in... 427: AC_CHECK_LIB([pq], [PQgetvalue],, AC_MSG_ERROR([no usable libpq; please install PostgreSQL devel package or equivalent]))
Is the test whether it can link to libpq by checking if the PQgetvalue function is available, problem is it doesn't seem to use the pg_config values. So on a system like yours where libpq is installing to somewhere other than the main lib directories it's unable to detect the libary.
File a Jira to track this if you haven't already done so.
Filed as FS-5512. My apologies for taking this to the list first rather than filing first. I thought that was the correct procudre. Lesson learned. Rgds, Claus
participants (2)
-
Claus Andersen
-
Steven Ayre