/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 [at] gallo.ucsf.edu

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--_000_C73DEAFC9163tsakaigalloucsfedu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Lew,

Thanks for your response. But I am more confused...

When I ran "ldd /usr/local/bin/pivot" on the machine I have
successfully compiled pivot.c, it returns:
libpq.so.5 =3D> /usr/local/pgsql/lib/libpq.so.5 (0x0000002a95557000=
)
libc.so.6 =3D> /lib64/tls/libc.so.6 (0x0000003b0dc00000)
libcrypt.so.1 =3D> /lib64/libcrypt.so.1 (0x0000003b12f00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b0da00000)
I check LD_LIBRARY_PATH variable on the centOS machine
(where I am trying to compile now), it returns:
LD_LIBRARY_PATH=3D/lib:/opt/gridengine/lib/lx26-x86:/state/p artition1/app=
s/pgsql/lib:/usr/local/lib:/opt/gridengine/lib/lx26-x86
and I find libpq.so, libpq.so.5, and libpq.so.5.1 in /state/partition1/app=
s/pgsql/lib
directory; libc.so.6 and libcrypt.so.1 both in /lib. Finally, the last one=
,
/lib64/ld-linux-x86-64.so.2 is a symbolic link to /lib64/ld-2.3.4.so (on
Redhat 64-bit machine). There is no such thing as ld-linux-x86-64.so.2
on centOS machine. However, there is /lib/ ld-linux.so.2 which is a
symbolic link to /lib/ld-2.5.so.

I don't really know what this means with respect to the error message:
/usr/bin/ld: cannot find -lpq
collect2: ld returned 1 exit status
Is there any way to extrapolate something a bit more relavant, I wonder.

Regards,

Tena Sakai
tsakai [at] gallo.ucsf.edu

On 12/3/09 8:26 PM, "Yon Lew" <lewyon [at] gmail.com> wrote:

Just a guess, but it sounds to me like a problem with $LD_LIBRARY_PATH.

Try running the ldd command to list your dependencies:

> ldd /bin/ls

librt.so.1 =3D> /lib64/librt.so.1 (0x00002b40a142b000)
libacl.so.1 =3D> /lib64/libacl.so.1 (0x00002b40a1534000)
libc.so.6 =3D> /lib64/libc.so.6 (0x00002b40a163b000)
libpthread.so.0 =3D> /lib64/libpthread.so.0 (0x00002b40a187c000)
/lib64/ld-linux-x86-64.so.2 (0x00002b40a130f000)
libattr.so.1 =3D> /lib64/libattr.so.1 (0x00002b40a1995000)

If you come up with unmatched dependencies try adding the path containing t=
he .so file, or its symbolic link, to your $LD_LIBRARY_PATH or $LD_LIBRARY_=
PATH_64 environment variable. When ldd comes back clean you should be good=
to go.

On Thu, Dec 3, 2009 at 7:25 PM, Tena Sakai <tsakai [at] gallo.ucsf.edu> wrote:
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 [at] gallo.ucsf.edu

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--_000_C73DEAFC9163tsakaigalloucsfedu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [ADMIN] /usr/bin/ld: cannot find -lpq</TITLE>
</HEAD>
<BODY>
H=
i Lew, 
 
Thanks for your response. But I am more confused... 
 
When I ran “ldd /usr/local/bin/pivot” on the machine I have 
successfully compiled pivot.c, it returns: 
 libpq.so.5 =3D> /usr/loc=
al/pgsql/lib/libpq.so.5 (0x0000002a95557000) 
 libc.so.6 =3D> /lib64/tl=
s/libc.so.6 (0x0000003b0dc00000) 
 libcrypt.so.1 =3D> /lib6=
4/libcrypt.so.1 (0x0000003b12f00000) 
 /lib64/ld-linux-x86-64.so.2=
(0x0000003b0da00000) 
I check LD_LIBRARY_PATH variable on the centOS machine 
(where I am trying to compile now), it returns: 
 LD_LIBRARY_PATH=3D/lib:/opt/gridengine/lib/lx26-x86:/state/p art=
ition1/apps/pgsql/lib:/usr/local/lib:/opt/gridengine/lib/lx2 6-x86 
and I find libpq.so, libpq.so.5, and libpq.so.5.1 in /state/partition=
1/apps/pgsql/lib 
directory; libc.so.6 and libcrypt.so.1 both in /lib. Finally, the las=
t one, 
/lib64/ld-linux-x86-64.so.2 is a symbolic link to /lib64/ld-2.3.4.so (on<BR=
>
Redhat 64-bit machine). There is no such thing as ld-linux-x86-64.so.=
2 
on centOS machine. However, there is /lib/ ld-linux.so.2 which is a<B=
R>
symbolic link to /lib/ld-2.5.so. 
 
I don’t really know what this means with respect to the error message=
: 
=A0/usr/bin/ld: cannot find -lpq 
=A0collect2: ld returned 1 exit status 
Is there any way to extrapolate something a bit more relavant, I wonder.<BR=
>
 
Regards, 
 
Tena Sakai 
tsakai [at] gallo.ucsf.edu 
 
 
On 12/3/09 8:26 PM, "Yon Lew" <lewyon [at] gmail.com> wrote: 
 
<BLOCKQUOTE>Just a guess, but it sounds to me like a problem w=
ith $LD_LIBRARY_PATH. 
 
Try running the ldd command to list your dependencies: 
 
> ldd /bin/ls 
 
librt.so.1 =3D> /lib64/librt.so.1 (0x00002b40a142b000) 
libacl.so.1 =3D> /lib64/libacl.so.1 (0x00002b40a1534000) 
libc.so.6 =3D> /lib64/libc.so.6 (0x00002b40a163b000) 
libpthread.so.0 =3D> /lib64/libpthread.so.0 (0x00002b40a187c000) 
/lib64/ld-linux-x86-64.so.2 (0x00002b40a130f000) 
libattr.so.1 =3D> /lib64/libattr.so.1 (0x00002b40a1995000) 
 
If you come up with unmatched dependencies try adding the path containing t=
he .so file, or its symbolic link, to your $LD_LIBRARY_PATH or $LD_LIBRARY_=
PATH_64 environment variable. =A0When ldd comes back clean you should be go=
od to go. 
 
 
 
On Thu, Dec 3, 2009 at 7:25 PM, Tena Sakai <tsakai [at] gallo.ucsf.edu> wr=
ote: 
<BLOCKQUOTE>Hi Everybody, 
 
I am not sure if this is the right mailing list to ask 
what I want to ask. =A0Please 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: 
 
=A0cc -I/pgsql/pgsql836/include -L/pgsql/pgsql836/lib -lpq -o pivot p=
ivot.c 
 
And I just tried recompiling it on that machine and it compiles without a<B=
R>
complaint. =A0I now need to re-compile it on a Intel 32-bit machine running=
 
centOS. =A0When I issue the same command on the centOS machine, I get 
complaint: 
=A0/usr/bin/ld: cannot find -lpq 
=A0collect2: ld returned 1 exit status 
 
I thought that this meant that the shared library named libpq.so.bla 
is missing. =A0But to my surprise, I find libpq.so.4.1 in /usr/lib 
directory. =A0(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 [at] gallo.ucsf.edu 
 
 
-- 
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org) 
To make changes to your subscription: 
<a href=3D"http://www.postgresql.org/mailpref/pgsql-admin">http://www.postg=
resql.org/mailpref/pgsql-admin</a> 
</BLOCKQUOTE>=
 
 
</BLOCKQUOTE> 

</BODY>
</HTML>

--_000_C73DEAFC9163tsakaigalloucsfedu_--

Tena Sakai <tsakai [at] 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

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--_000_C73DF6D3916Dtsakaigalloucsfedu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Tom,

Thank you so much for your insight.
I didn't mean to lie to you, but unintentionally I omitted a thing
or two. When I compiled it first time, it complained as to libpq-fe.h
was missing. I thought it was hidden somewhere and in a rush I
just copied it into the current directory (where the source code is)
and recompiled. It went on to complain about another include file
which I again supplied to the same place and when I compiled it
the third time it gave me the error I reported.

So, it seems that what I have to do is to rebuild/reinstall postgres
with postgresql-devel. Is this an option to configure on the top-level
directory? Can you please tell me how I include it?

Thank you.

Regards,

Tena Sakai
tsakai [at] gallo.ucsf.edu

On 12/3/09 10:21 PM, "Tom Lane" <tgl [at] sss.pgh.pa.us> wrote:

Tena Sakai <tsakai [at] 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

--_000_C73DF6D3916Dtsakaigalloucsfedu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [ADMIN] /usr/bin/ld: cannot find -lpq </TITLE>
</HEAD>
<BODY>
H=
i Tom, 
 
Thank you so much for your insight. 
I didn’t mean to lie to you, but unintentionally I omitted a thing<BR=
>
or two. When I compiled it first time, it complained as to libp=
q-fe.h 
was missing. I thought it was hidden somewhere and in a rush I<=
BR>
just copied it into the current directory (where the source code is)<=
BR>
and recompiled. It went on to complain about another include fi=
le 
which I again supplied to the same place and when I compiled it 
the third time it gave me the error I reported. 
 
So, it seems that what I have to do is to rebuild/reinstall postgres 
with postgresql-devel. Is this an option to configure on the top-leve=
l 
directory? Can you please tell me how I include it? 
 
Thank you. 
 
Regards, 
 
Tena Sakai 
tsakai [at] gallo.ucsf.edu 
 
 
On 12/3/09 10:21 PM, "Tom Lane" <tgl [at] sss.pgh.pa.us> wrote:<=
BR>
 
<BLOCKQUOTE>Tena Sakai <tsakai [at] gallo.ucsf.edu> writes:<B=
R>
> ... I just tried recompiling it on that machine and it compiles withou=
t 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 g=
et 
> 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<B=
R>
> is missing. But to my surprise, I find libpq.so.4.1 in /usr/lib<=
BR>
> 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. 
 
 &nb=
sp; regard=
s, tom lane 
 
</BLOCKQUOTE> 

</BODY>
</HTML>

--_000_C73DF6D3916Dtsakaigalloucsfedu_--

--_000_C73E0D029179tsakaigalloucsfedu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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
tsakai [at] gallo.ucsf.edu

On 12/3/09 10:21 PM, "Tom Lane" <tgl [at] sss.pgh.pa.us> wrote:

Tena Sakai <tsakai [at] 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

--_000_C73E0D029179tsakaigalloucsfedu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [ADMIN] /usr/bin/ld: cannot find -lpq </TITLE>
</HEAD>
<BODY>
H=
i Tom, 
 
Please ignore what I wrote before. I got it. I mean I got it co=
mpiled 
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 screw=
ed 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 
tsakai [at] gallo.ucsf.edu 
 
 
On 12/3/09 10:21 PM, "Tom Lane" <tgl [at] sss.pgh.pa.us> wrote:<=
BR>
 
<BLOCKQUOTE>Tena Sakai <tsakai [at] gallo.ucsf.edu> writes:<B=
R>
> ... I just tried recompiling it on that machine and it compiles withou=
t 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 g=
et 
> 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<B=
R>
> is missing. But to my surprise, I find libpq.so.4.1 in /usr/lib<=
BR>
> 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. 
 
 &nb=
sp; regard=
s, tom lane 
 
</BLOCKQUOTE> 

</BODY>
</HTML>

--_000_C73E0D029179tsakaigalloucsfedu_--

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.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--_000_C73E9BBA91AAtsakaigalloucsfedu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

Thank you for an excellent idea. I'll make note of it.

Regards,

Tena Sakai
tsakai [at] gallo.ucsf.edu

On 12/4/09 5:18 AM, "Alvaro Herrera" <alvherre [at] commandprompt.com> wrote:

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.

--_000_C73E9BBA91AAtsakaigalloucsfedu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [ADMIN] /usr/bin/ld: cannot find -lpq</TITLE>
</HEAD>
<BODY>
H=
i Alvaro, 
 
Thank you for an excellent idea. I’ll make note of it. 
 
Regards, 
 
Tena Sakai 
tsakai [at] gallo.ucsf.edu 
 
 
On 12/4/09 5:18 AM, "Alvaro Herrera" <alvherre [at] commandprompt.c=
om> wrote: 
 
<BLOCKQUOTE>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. &nbs=
p;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 m=
y 
> alias. Therefore it didn't find the libpq-fe.h file and I screwe=
d that 
> up even worse by supplying desired files in the current directory 
> from the other machine. I corrected the alias, removed the heade=
r 
> files in the source directory, and then compilation went smoothly and<=
BR>
> 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 =
 &nb=
sp; <a href=3D"http://www.Co=
mmandPrompt.com/">http://www.CommandPrompt.com/</a> 
The PostgreSQL Company - Command Prompt, Inc. 
 
</BLOCKQUOTE> 

</BODY>
</HTML>

--_000_C73E9BBA91AAtsakaigalloucsfedu_--

/usr/bin/ld: cannot find -lpq

Re: /usr/bin/ld: cannot find -lpq

Re: /usr/bin/ld: cannot find -lpq

Re: /usr/bin/ld: cannot find -lpq

Re: /usr/bin/ld: cannot find -lpq

Re: /usr/bin/ld: cannot find -lpq

Re: /usr/bin/ld: cannot find -lpq