The recent PQisthreadsafe configure check change seems to be broken on 
systems that don't have libpq installed in a standard place.

configure:7664: result: yes
configure:7679: checking for PQfreemem in -lpq
configure:7714: /usr/bin/gcc-4.3.2 -o conftest -g -O2 
-I/usr/local/pgsql9.0/include/ -I/usr/local/pgsql9.0/include/server/ 
-L/usr/local/pgsql9.0/lib/ conftest.c -lpq   >&5
configure:7720: $? = 0
configure:7738: result: yes
configure:7753: checking PostgreSQL for thread-safety
configure:7786: /usr/bin/gcc-4.3.2 -o conftest -g -O2 
-I/usr/local/pgsql9.0/include/ -I/usr/local/pgsql9.0/include/server/ 
-L/usr/local/pgsql9.0/lib/ conftest.c  -lpq >&5
configure:7789: $? = 0
configure:7795: ./conftest
ld.so.1: conftest: fatal: libpq.so.5: open failed: No such file or directory
configure:7798: $? = 265
configure: program exited with status 265


The compile is finding libpq via the -L but when we go to execute the 
compiled program it can't find libpq.

One option is to set LD_LIBRARY_PATH but doing this directly might not 
be very portable (AIX uses LIBPATH for this purpose, but AIX also embeds 
the full runtime path into the library)


Another option is to compile the test with -rpath.  This would make 
sense except the the syntax for that isn't portable either.

Solaris(sun linker), FreeBSD:  -R
Linux, GNU linker most places: -rpath
AIX: -blibpath
HPUX: something else

(The above is based on looking grepping for rpath in src/makefiles/ in 
the postgresql source tree).

Will we have to implement this type of logic in autoconf? or does 
someone have a better idea?





-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142