5

I'm trying to build a very simple PostgreSQL client in C over Cygwin.

Here's what I've done so far:

  • I've downloaded the PostgreSQL source code version 9.1.2 (to match the same version that is running on my server)
  • I've configured and compiled the source code from Cygwin. The compilation seemed to go smoothly.
  • From what I can tell, the header files are in:
    • /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq, and
    • /cygdrive/c/workspace/src/postgresql-9.1.2/src/include
  • The libraries are in:
    • /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq

From here, I compiled and linked the client program using the makefile below:

testlibpq: testlibpq.c
    gcc -o testlibpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/include -L /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq testlibpq.c -Bstatic -lpq

The compilation and the linking succeeded without errors or warnings.

However, when I try to run the program, I get the following error:

$ ./testlibpq
/cygdrive/c/Users/dleclair/Dropbox/denis/src/testlibpq/testlibpq.exe: error while loading shared libraries: cygpq.dll: cannot open shared object file: No such file or directory

I haven't figured out how to fix this. Any pointers would be greatly appreciated. Oh, one more thing, I found the folder that cygpq.dll was sitting in and set my LD_LIBRARY_PATH to point to it but it still gave me the same result.

dleclair@dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ ls /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
bcc32.mak      encnames.o    fe-connect.o  fe-misc.o       fe-protocol3.o   ip.o           libpq-events.c  md5.c                   pgstrcasecmp.c  pqsignal.c       thread.o
blibpqdll.def  exports.txt   fe-exec.c     fe-print.c      fe-secure.c      libpq.a        libpq-events.h  md5.o                   pgstrcasecmp.o  pqsignal.h       wchar.c
chklocale.c    fe-auth.c     fe-exec.o     fe-print.o      fe-secure.o      libpq.rc.in    libpq-events.o  nls.mk                  po              pqsignal.o       wchar.o
chklocale.o    fe-auth.h     fe-lobj.c     fe-protocol2.c  inet_net_ntop.c  libpqddll.def  libpq-fe.h      noblock.c               pqexpbuffer.c   pthread-win32.c  win32.c
cygpq.dll      fe-auth.o     fe-lobj.o     fe-protocol2.o  inet_net_ntop.o  libpq-dist.rc  libpq-int.h     noblock.o               pqexpbuffer.h   README           win32.h
encnames.c     fe-connect.c  fe-misc.c     fe-protocol3.c  ip.c             libpqdll.def   Makefile        pg_service.conf.sample  pqexpbuffer.o   thread.c         win32.mak

dleclair@dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ echo $LD_LIBRARY_PATH
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq

dleclair@dleclair-win7l ~/Dropbox/denis/src/testlibpq
Milen A. Radev
  • 60,241
  • 22
  • 105
  • 110
Denis
  • 1,031
  • 3
  • 11
  • 22
  • Not an answer, but: IMO cygwin is a recipe for pain and suffering. It's weird and sometimes just broken. Unless you specifically need its features you are *much* better off writing portable code with some abstraction interfaces for platform specifics, then writing platform support layers for UNIX and Windows. On windows, compile the software with msys/mingw, or with Microsoft Visual Studio Express Edition / Windows Platform SDK. Great question, btw; thanks for all the detail. – Craig Ringer Nov 04 '12 at 00:59
  • One thought: with the native Windows dynamic linker, if you have program `X` that links to `A.dll`, if `A.dll` `B.dll`, and if `B.dll` cannot be found, you will get an error very similar to `A.dll: no such file or directory`. What it *means* is `While loading A.dll and its dependencies I got this error:` but it's most unclear. It's possible Cygwin has the same issue. Check `ldd cygpq.dll` to verify that all the libraries it requires can be found on the search path. – Craig Ringer Nov 04 '12 at 01:04
  • I think you're right about the association of Cygwin with pain and suffering. After struggling with it for a bit, I decided in the end that I would edit the source files on my local Windows machine and then, through the magic of Dropbox, I would compile and run via a remote shell to my Linux server which happens to be hosting the database anyway. With the exception of a little bit of lag (~5-10 seconds or so) in the Dropbox file sync, this is working surprisingly well. – Denis Nov 04 '12 at 13:34

1 Answers1

1

Normally on unix/linux systems after building the source a make install is done which copies the headers to standard locations like /usr/local/include and /usr/local/lib. You may have to do that on cygwin to to get the DLL in the search path.

Or you can just locate the DLL yourself and put it on the search path or in the same folder as your executable.

Eelke
  • 20,897
  • 4
  • 50
  • 76
  • I like your suggestion of copying the DLL to my local directory. I might give that a try but I'm not sure when because as I describe in my comment above, I've moved on with compiling and running the code on Linux. – Denis Nov 04 '12 at 13:37