Обсуждение: Which header and lib files to use when compiling libpq-code?
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.)
I tried the naive approach of using the "newest" versions of these files, as 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.
But this method of determining the correct header and library files is still too fraught with uncertainty for my taste. Is there an approach to this problem that involves less guesswork?
Thanks!
Kynn
On Mon, Apr 27, 2009 at 10:51:45AM -0400, Kynn Jones wrote: > 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.) In general you don't need to match the server version, the protocol hasn't changed much in a while so as long as it's less than a few years old it'll work. New versions have more features though, obviously. > I tried the naive approach of using the "newest" versions of these files, as > 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. Given you're using Ubuntu, why not just install postgresql-dev and use /usr/include/postgresql. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
Вложения
On Mon, Apr 27, 2009 at 11:10 AM, Martijn van Oosterhout <kleptog@svana.org> 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
Kynn Jones <kynnjo@gmail.com> writes: > On Mon, Apr 27, 2009 at 11:10 AM, Martijn van Oosterhout > <kleptog@svana.org>wrote: >> In general you don't need to match the server version, the protocol >> 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. What that probably means is you picked a header file that didn't match the libpq.so shared library version. Martijn's statement that libpq is insensitive to the *server* version is generally correct. regards, tom lane
On Mon, Apr 27, 2009 at 12:27:37PM -0400, Kynn Jones wrote: > On Mon, Apr 27, 2009 at 11:10 AM, Martijn van Oosterhout > <kleptog@svana.org>wrote: > > In general you don't need to match the server version, the protocol > > 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. In which case you're going to need to provide a lot more information, because it really doesn't matter unless you've got really old versions. The client talks to the server using a socket and if you're getting memory corruption then it looks more like someone broke your compiler than that you're not matching the server version. > 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. You can't really. Any libpq newer than 7.4 (released 2003) should be able to talk to anything newer 6.4 (released 1998) makes it unlikely you're going to run into problems compatability-wise. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.