On Mon, Apr 27, 2009 at 11:10 AM, Martijn van Oosterhout <kleptog@xxxxxxxxx> wrote:
On Mon, Apr 27, 2009 at 10:51:45AM -0400, Kynn Jones wrote:In general you don't need to match the server version, the protocol
> I need to compile some code that uses libpq. For this I need to determine
> the directories to use for the header and library files.
>
> The machine I'm using has multiple copies of the files libpq-fe.h and
> libpq.a. How can I determine which one of all these copies are the ones
> that correspond to the Pg server that is currently running on this system?
> (FWIW, the OS here is Ubuntu Linux.)
hasn't changed much in a while so as long as it's less than a few years
old it'll work.
This statement contradicts the experience I described in my original post: the choice of header and/or library files is absolutely critical. The wrong choice lead to very bizarre connection failures.
> I tried the naive approach of using the "newest" versions of these files, asGiven you're using Ubuntu, why not just install postgresql-dev and use
> measured by their modification times. This produced disastrous results.
> The code compiled, but resulted in a program that failed in bizarre and
> unpredictable ways, which strongly hinted at one or more silent segmentation
> violations in the C code. I conjectured that this was the result of a
> mismatched header or library file. Sure enough, the bizarre failures
> disappeared when I used a different set of header and library files.
/usr/include/postgresql.
I don't have root privileges on this machine, so I could not install postgresql-dev, but, as it happens, /usr/include/postgresql already exists in this machine, in it is, in fact, the version that worked.
But this is not the problem that my question was about. The problem is: *how to ensure* that the versions of libpq header and library files used for compiling programs will work properly with a specific Postgres server.
kynn
