Hi Tom,
Please ignore what I wrote before. I got it. I mean I got it compiled
successfully on the centOS machine. I was stupid and blind. In order
to compile, I created an alias for cc with long string for include and
lib directories. Which was not a bad idea, but I had a typo in my
alias. Therefore it didn't find the libpq-fe.h file and I screwed that
up even worse by supplying desired files in the current directory
from the other machine. I corrected the alias, removed the header
files in the source directory, and then compilation went smoothly and
I can now test the program.
My apologies.
Regards,
Tena Sakai
tsa...@gallo.ucsf.edu
On 12/3/09 10:21 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote:
Tena Sakai <tsa...@gallo.ucsf.edu> writes:
> ... I just tried recompiling it on that machine and it compiles without a
> complaint. I now need to re-compile it on a Intel 32-bit machine running
> centOS. When I issue the same command on the centOS machine, I get
> complaint:
> /usr/bin/ld: cannot find -lpq
> collect2: ld returned 1 exit status
> I thought that this meant that the shared library named libpq.so.bla
> is missing. But to my surprise, I find libpq.so.4.1 in /usr/lib
> directory. (There is also a symbolic link libpq.so.4 pointing at
> libpq.so.4.1 in the same place.)
What you need to build a program relying on a shared library is
libfoo.so --- not libfoo.so.n, which is what is used at runtime.
Normally, libfoo.so is a symlink provided by the -devel package
for the library. In short, then, your problem is that you don't
have postgresql-devel installed. What seems odd is that you got
this far, because postgresql-devel also carries the header files
you need for compiling callers of libpq (ie, /usr/include/libpq-fe.h).
I'd have expected a failure mentioning lack of libpq-fe.h. Seems
like you must have some sort of broken partial installation on
that machine.
regards, tom lane
