Thread: Mac OS X 10.6 - libpq.dylib vs. libpq.a and PQisthreadsafe()
Hello,
I've been getting acquainted with the C interface for libpq and have run into an issue with trying to link to the dynamic libpq while still getting thread safety. I have tried the following by compiling the 9.1 source with the --enable-thread-safety flag and I've tried the libpq libraries provided in the EnterpriseDB build of 9.1. All of this is on Mac OS X 10.6.8 with XCode 4.0.2.
The problem I'm having is that PQisthreadsafe() returns 0 when I link to the dynamic library(libpq.5.4.dylib), but it returns 1 when I link to the static library (libpq.a). The code I'm using is as follows:
#include "libpq-fe.h"
int main (int argc, const char * argv[])
{
if (PQisthreadsafe() == 1) {
puts("Thread safe");
} else {
puts("Not thread safe");
}
}
Commands and output (main.c, libpq.a and libpq.5.4.dylib are all in the same directory):
gcc -I /Library/PostgreSQL/9.1/include main.c libpq.a -o main
Output: "Thread safe"
gcc -I /Library/PostgreSQL/9.1/include main.c libpq.5.4.dylib -o main
Output: "Not thread safe"
I'm admittedly not great with the nuances of the linker or with the PostgreSQL C interface so it's possible I'm missing something obvious here. If anyone knows how I should be using libpq as a dynamic library with thread safety, then that would be a great help.
Regards,
__________________________________
David McKeone
Arts Management Systems Ltd.
Phone: (403) 536-1203 Fax: (403) 536-1210
David McKeone <david@artsman.com> writes:
> I've been getting acquainted with the C interface for libpq and have run into an issue with trying to link to the
dynamiclibpq while still getting thread safety. I have tried the following by compiling the 9.1 source with the
--enable-thread-safetyflag and I've tried the libpq libraries provided in the EnterpriseDB build of 9.1. All of this
ison Mac OS X 10.6.8 with XCode 4.0.2.
Hm, is there a libpq dylib in /usr/lib? If so, maybe it's capturing the
reference? "otool -L main" would be informative about which dylib is
actually getting called, I think. If it's not what you expected, the
lack of a -L switch in your link command is probably the reason.
regards, tom lane
On 2011-10-17, at 4:23 PM, Tom Lane wrote:
Hm, is there a libpq dylib in /usr/lib? If so, maybe it's capturing the
reference? "otool -L main" would be informative about which dylib is
actually getting called, I think. If it's not what you expected, the
lack of a -L switch in your link command is probably the reason.
regards, tom lane
Here is the output for otool -L for both.
Static libpq.a
main:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
Dynamic libpq.5.4.dylib using -lpq
main:
libpq.5.dylib (compatibility version 5.0.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
Dynamic libpq.5.4.dylib using the command from the previous email (This one is interesting because /usr/local/pgsql doesn't exist on this machine)
main:
/usr/local/pgsql/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
I did have a libpq.5.dylib in /usr/lib and it turns out that that was the problem. So it looks like, even though I was specifying the library, it just picked the one at /usr/lib version anyway. (I obviously have much more to learn about how the linker works on OS X)
The solution was to move the Enterprise DB libpq.5.4.dylib into /usr/lib (and create associated symlinks) and it worked correctly after that.
Thanks for pointing me in the right direction.