Обсуждение: /usr/bin/ld: cannot find -lpq

Hi Everybody,

I am not sure if this is the right mailing list to ask
what I want to ask.  Please direct me to the right place,
if there is a better list.

Close to a year ago, I wrote a C program using libpq package.
It took me a week to debug, but I got it compiled and I have
been using it regularly. The program is named pivot and compiled
on a Redhat linux (AMD 64-bit) machine with the command:

  cc -I/pgsql/pgsql836/include -L/pgsql/pgsql836/lib -lpq -o pivot pivot.c

And 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.)

So, I don't know what the complaint is about.

Can someone please clue me in?

Thank you in advance.

Regards,

Tena Sakai
tsakai@gallo.ucsf.edu

Tena Sakai <tsakai@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

Tena Sakai <tsakai@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

Tena Sakai <tsakai@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

Tena Sakai wrote:
> 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.

FWIW you should always prefer pg_config to help you get the right
compile flags; something like

gcc -I`pg_config --includedir` -L`pg_config --libdir` -lpq ...

That gets you the right include and lib dirs.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Tena Sakai wrote:
> 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.

FWIW you should always prefer pg_config to help you get the right
compile flags; something like

gcc -I`pg_config --includedir` -L`pg_config --libdir` -lpq ...

That gets you the right include and lib dirs.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.