Hi all,
I'm having a lot of trouble developing with PostgreSQL on OS X and
I've tracked it down to the way that various client libraries are
compiled and installed. I'll use the ecpg library as an example. With
PostgreSQL 8.4.5 on OS X we have the library "libecpg.6.1.dylib" and
two symbol links to it from "libecpg.6.dylib" and "libecpg.dylib".
These all live in /Library/PostgreSQL/8.4/lib. I (and most other
people I guess) link to it with a command like "gcc ... -L/Library/
PostgreSQL/8.4/lib -lecpg" and linking works fine. The linker reads
the install name from libecpg.6.1.dylib and stores it in my executable
so that it can load the correct shared library and runtime.
Unfortunately the install name in all the PostgreSQL libraries on the
Mac are unqualified names such as "libecpg.6.dylib" instead of full
pathnames like "/Library/PostgreSQL/8.4/lib/libecpg.6.dylib" meaning
that no PostgreSQL client program on OS X can possibly ever run
because the runtime linker doesn't know where the files are. That's
obviously crazy because plenty of PostgreSQL clients run fine. It gets
worse.
The programs that run fine only do so because the installer puts a
symbolic link in /usr/lib for libpq.5.dylib. Libraries in /usr/lib can
always be found and so most things work. I've double checked with
other software I have installed and their libraries always have the
full pathname recorded as their install name.
My problem is that I don't know who will want to own which bugs. The
install name can be set in the library at compile time by ld(1), or at
package install time by install_name_tool(1). In the latter case, a
compile time option must be used to reserve enough space in the
library for the correct install name to be set. The /usr/lib symlink
is a nasty hack that fails as soon as you have two different versions
of PostgreSQL installed.
Cheers,
Lloyd
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
