Re: Whose bug is this? - Mailing list pgsql-general

From Tom Lane
Subject Re: Whose bug is this?
Date
Msg-id 29799.1290093760@sss.pgh.pa.us
Whole thread Raw
In response to Whose bug is this?  (Lloyd Parkes <lloyd@must-have-coffee.gen.nz>)
Responses Re: Whose bug is this?  (Scott Ribe <scott_ribe@elevated-dev.com>)
List pgsql-general
Lloyd Parkes <lloyd@must-have-coffee.gen.nz> writes:
> 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.

AFAICT, the way this works on OS X is that

(1) At the time of shared library build, you specify its eventual
install location with "-install_name /full/path/and/filename".

(2) When an executable is linked against such a library, the
install_name is recorded in the executable (whether the library was
found in that location or not --- this supports linking in a build
tree).

(3) At runtime, the library had better be in the declared location.

So what the symptoms sound like is that you're trying to use libraries
that were built to be in someplace other than where they are.
"otool" might help you in figuring out their intended location.

You say that the recorded install_name is just the library name without
path --- how sure are you of that?  Because it appears to me that the
Postgres makefiles will always specify a full path when building a shlib
on Darwin.  Somebody would have had to hack up src/Makefile.shlib, or
munge the libraries after the fact, to get a path-less install_name.

> My problem is that I don't know who will want to own which bugs.

A build from the unmodified sources works fine for me on OS X.
I think the error is either yours or whoever built the PG package
you're using.

            regards, tom lane

pgsql-general by date:

Previous
From: Willy-Bas Loos
Date:
Subject: Re: where is pg_stat_activity (and others) in the documentation?
Next
From: Tom Lane
Date:
Subject: Re: ERROR row is too big size 9336, exceeds size 8160 when populating record with tsquery and tsvector fields