Обсуждение: libpq.so.3 not found
Hi,all I am working on solaris platform. When I try to create an executable file using gcc -o -L -lpq, it gives me an error message: ld.so.1: file_name: fatal: libpq.so.3: open failed: No such file or directory But I give the full path of lib files in -L option. And libpq.so.3 is right there. Can anyone help me? Thanks a lot. Xinyu
Xinyu Hua <xhua@cse.ucsc.edu> writes:
> I am working on solaris platform.
> When I try to create an executable file using gcc -o -L -lpq, it gives me
> an error message:
> ld.so.1: file_name: fatal: libpq.so.3: open failed: No such file or
> directory
> But I give the full path of lib files in -L option. And libpq.so.3 is
> right there.
Dynamic linker error messages are notoriously unhelpful :-(. I'll bet
it's really complaining about not being able to find some library that
libpq.so depends on. You should be able to use ldd (or local equivalent)
to inspect the list of libraries that libpq.so needs, and from there
figure out what the problem is.
regards, tom lane
On Mon, 8 Sep 2003, Tom Lane wrote: > Xinyu Hua <xhua@cse.ucsc.edu> writes: > > I am working on solaris platform. > > When I try to create an executable file using gcc -o -L -lpq, it gives me > > an error message: > > ld.so.1: file_name: fatal: libpq.so.3: open failed: No such file or > > directory > > But I give the full path of lib files in -L option. And libpq.so.3 is > > right there. > > Dynamic linker error messages are notoriously unhelpful :-(. I'll bet > it's really complaining about not being able to find some library that > libpq.so depends on. You should be able to use ldd (or local equivalent) > to inspect the list of libraries that libpq.so needs, and from there > figure out what the problem is. Tom, I think all the libraries that libpq.so needs are right there. Please see the following:libresolv.so.2 => /usr/lib/libresolv.so.2 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2=> /usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 sundance 50> ls /usr/lib/libsocket.so.1 /usr/lib/libsocket.so.1* sundance 51> ls /usr/lib/libnsl.so.1 /usr/lib/libnsl.so.1* sundance 52> ls /usr/local/lib/libgcc_s.so.1 /usr/local/lib/libgcc_s.so.1 sundance 53> ls /usr/lib/libc.so.1 /usr/lib/libc.so.1* sundance 54> ls /usr/lib/libdl.so.1 /usr/lib/libdl.so.1* sundance 55> ls /usr/lib/libmp.so.2 /usr/lib/libmp.so.2* sundance 56> ls /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1@ So what else could be wrong? Thank you very much. Xinyu
Xinyu Hua <xhua@cse.ucsc.edu> writes:
> Tom, I think all the libraries that libpq.so needs are right there. Please
> see the following:
> libresolv.so.2 => /usr/lib/libresolv.so.2
> libsocket.so.1 => /usr/lib/libsocket.so.1
> libnsl.so.1 => /usr/lib/libnsl.so.1
> libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
Almost certainly, the problem is that /usr/local/lib/ isn't getting
searched and so libgcc_s.so isn't found. This sort of problem is easily
hit because different bits of code have different ideas about where to
search for shared libraries. I think ldd pays attention to
LD_LIBRARY_PATH, but gcc only pays attention to -L switches.
regards, tom lane
On Mon, 8 Sep 2003, Tom Lane wrote: > Xinyu Hua <xhua@cse.ucsc.edu> writes: > > Tom, I think all the libraries that libpq.so needs are right there. Please > > see the following: > > libresolv.so.2 => /usr/lib/libresolv.so.2 > > libsocket.so.1 => /usr/lib/libsocket.so.1 > > libnsl.so.1 => /usr/lib/libnsl.so.1 > > libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 > > Almost certainly, the problem is that /usr/local/lib/ isn't getting > searched and so libgcc_s.so isn't found. This sort of problem is easily > hit because different bits of code have different ideas about where to > search for shared libraries. I think ldd pays attention to > LD_LIBRARY_PATH, but gcc only pays attention to -L switches. > Tom, how can i fix that? I specified -L/usr/local/lib, but it does not work. Thank you so much. Xinyu
Xinyu Hua <xhua@cse.ucsc.edu> writes:
> Tom, how can i fix that? I specified -L/usr/local/lib, but it does not
> work. Thank you so much.
In that case I'm out of ideas :-(. Anyone else care to take a swing?
regards, tom lane
On Mon, 8 Sep 2003, Tom Lane wrote: > Xinyu Hua <xhua@cse.ucsc.edu> writes: > > Tom, how can i fix that? I specified -L/usr/local/lib, but it does not > > work. Thank you so much. > > In that case I'm out of ideas :-(. Anyone else care to take a swing? > k Try adding the -v switch to gcc just to verify that the commands look sensible. Isn't there also something that makes the indiviudal stages like ld more verbose? Could it be that in the linking stage it's picking up the wrong ld and that's somehow not looking in the same locations? -- Nigel Andrews
On Tue, 9 Sep 2003 01:55 pm, Tom Lane wrote: > In that case I'm out of ideas :-(. Anyone else care to take a swing? I'm game - I hit a similar problem on my old Sparc box last night (not related to libpq specifically). I did this: $ uname -a SunOS sparc4 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4 $ gcc -lpthread test.c # this is Bruce's thread test app Undefined first referencedsymbol in file gethostbyname /var/tmp/cc31rpyq.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status $ gcc -lpthread -lnsl test.c # this works libnsl contains the gethostbyname function... why on earth I had to tell the linker to actually link against it, I do not know, especially since I didn't need to tell it -L/usr/lib to locate the .so... maybe if you're still stuck, try telling it to link against absolutely everything. Regards, Philip.