3:51 p.m.
I have PostgreSQL v8 installed from DarwinPorts on Mac OS X 10.3.9.
libpq is linked with SSL and libcrypto. I've gotten configure to
detect, and the PostgreSQL modules to build with the following patch
to configure.ac. But I don't much like it:
- there's got to be a cleaner way to defeat the autocrock cache
- I suspect there are platforms that don't need libcrypto
- if other platforms work differently, the code is tedious to
generalize
Suggestions welcome!
diff -rN -u old-xft-integration-new/configure.ac new-xft-integration-new/configure.ac
--- old-xft-integration-new/configure.ac 2005-11-05 00:45:09.000000000 +0900
+++ new-xft-integration-new/configure.ac 2005-11-05 00:45:17.000000000 +0900
＠＠ -3778,16 +3778,33 ＠＠
libpq_fe_h_file=${header_dir}libpq-fe.h; break)
done
- test -n "$libpq_fe_h_file" && {
AC_CHECK_LIB(pq,PQconnectdb,have_libpq=yes) }
+ pq_libs=
+ extra_libs=
+ if test -n "$libpq_fe_h_file"; then
+dnl for extra_libs in "" "-lssl"; do
+dnl AC_CHECKING([for PQconnectdb in -lpq $extra_libs])
+dnl AC_CHECK_LIB(pq, PQconnectdb,
+dnl [pq_libs="-lpq $extra_libs"; break], [:], $extra_libs)
+dnl done
+ AC_CHECK_LIB(pq, PQconnectdb,[pq_libs="-lpq"],[
+ unset ac_cv_lib_pq_PQconnectdb;
+ AC_CHECK_LIB(pq, PQconnectdb,[pq_libs="-lpq -lcrypto -lssl"],,
+ [-lcrypto -lssl])])
+ if test -z "$pq_libs"; then
+ have_libpq="no"
+ else
+ have_libpq="yes"
+ fi
+ fi
if test -n "$libpq_fe_h_file" -a "$have_libpq" = "yes";
then
with_postgresql=yes
AC_DEFINE(HAVE_POSTGRESQL)
AC_CHECK_LIB(pq,PQconnectStart, [
with_postgresqlv7=yes;
- AC_DEFINE(HAVE_POSTGRESQLV7)])
+ AC_DEFINE(HAVE_POSTGRESQLV7)], [:], $extra_libs)
AC_DEFINE_UNQUOTED(LIBPQ_FE_H_FILE, "$libpq_fe_h_file")
- XE_PREPEND(-lpq, postgresql_libs)
+ XE_PREPEND([$pq_libs], postgresql_libs)
XE_APPEND(modules/postgresql, MAKE_SUBDIR)
need_modules_common=yes
if test "$enable_modules" = "yes"; then
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:43 p.m.
On Sat, 2005-11-05 at 00:51 +0900, Stephen J. Turnbull wrote:
I have PostgreSQL v8 installed from DarwinPorts on Mac OS X 10.3.9.
libpq is linked with SSL and libcrypto. I've gotten configure to
detect, and the PostgreSQL modules to build with the following patch
to configure.ac. But I don't much like it:
- there's got to be a cleaner way to defeat the autocrock cache
- I suspect there are platforms that don't need libcrypto
- if other platforms work differently, the code is tedious to
generalize
Suggestions welcome!
This is not going to help with the problem at hand [1], but I wonder why
configure.ac is not using pg_config(1) for querying the location of
these headers and libraries, but relies on guesswork instead? pg_config
is available in PostgreSQL 7.1 and later.
[1] pg_config lacks the --libs or similar option :(
5:28 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> This is not going to help with the problem at hand [1], but
Ville> I wonder why configure.ac is not using pg_config(1)
The code was last seriously revised when 7.0 was in beta, that's why.
I don't know whether it needs to be backward compatible to < 7.1,
though.
Anyway, it's only in the last 18 months that *config programs have
started to really converge on useful functionality. If you already
know how to guess, why fight with a *config program?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8:09 a.m.
On Sat, 2005-11-05 at 14:28 +0900, Stephen J. Turnbull wrote:
Anyway, it's only in the last 18 months that *config programs
have
started to really converge on useful functionality. If you already
know how to guess, why fight with a *config program?
I find using a *config program or a pkgconfig *.pc file more future
proof than that. Anyway, I missed the --with-site-prefixes option which
will help in most cases, but probably not all. But as nobody has (IIRC)
complained, I guess it does it jobs sufficiently well.
8:05 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> I find using a *config program or a pkgconfig *.pc file
Ville> more future proof than that.
In theory, but the code I'm modifying basically goes back to 1999 IIRC
and still works for *finding* PostgreSQL. It's diagnosing the
additional libraries where it falls down. And as you point out,
pg_config doesn't do the --lib stuff that I'm working on. So tell me
again about future proofing when the technology has succeeded at least
once in the past. ;-)
Jokes aside, I'm all for portability. pkgconfig probably _does_ give
it by now, but none of the programs I hack configure for use it (I
think I was told about one exception, probably freetype, a couple of
months ago but haven't got around to picking up on that). All of the
ad hoc programs suffer from the same kind of problem that pg_config
does: they don't work in as many contexts as autoconf hackery does, so
you need to do the autoconf hackery anyway.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6959
days inactive
6961
days old
4 comments
2 participants
participants (2)
-
Stephen J. Turnbull -
Ville Skyttä