Thread: configure; make on cygwin doesn't produce DLLs
[After posting this on the postgresql-cygwin mailing list I realized it has had very low traffic in 2006. I hope it's ok to re-post my question here.] Hi, I'm trying to compile postgres-8.2.0 from source on WinXP-SP2, for use with libpqxx. At first I was able to compile in cygwin with ./configure followed by make. However, postgres-8.2.0/src/interfaces/libpq/Debug and libpqd.dll were not created, just Release and libpq.dll, much as Brian Doyle (this list and http://gborg.postgresql.org/pipermail/libpqxx-general/2006-July/001360.html) and others have experienced. I'd like to get to the point of following Bart Samwell's advice to use nmake, but unfortunately something else has gone wrong upstream. After accidentally mucking up the directory, I re-untarred the postgresql src package, uninstalled postgres packages from cygwin and PostgreSQL from Windows, rebooted, and started over. Now, from a clean src package, I get different behavior from configure. Formerly, it seemed to build as for win32. I had a spot of trouble the first time through with the compiler finding src/port/pg_config_paths.h wile compiling in src/interfaces/ecpg/ecpglib. This problem did not remanifest. Unfortunately I didn't capture the configure output the one time it worked, but looking at the output now, configure is using the cygwin template rather than the win32 one. Make doesn't error; neither does it produce libpq.dll and Release much less libpqd.dll and Debug. Short of a clean machine with a fresh install of cygwin (which I can't afford to do; other software depends on it in fragile ways), I'm stumped. Does anyone have any suggestions for getting configure/make to produce these DLLs? I will eventually be compiling libpqxx and then my client program with MSVC 2005, so if I am barking up the wrong tree altogether, please do say so :) Curran
If this is not the right list for this problem, could someone please point me to the right area? Curran Schiefelbein wrote: > > Hi, > > I'm trying to compile postgres-8.2.0 from source on WinXP-SP2, for use > with libpqxx. > > At first I was able to compile in cygwin with ./configure followed by > make. However, postgres-8.2.0/src/interfaces/libpq/Debug and libpqd.dll > were not created, just Release and libpq.dll, much as Brian Doyle (this > list and > http://gborg.postgresql.org/pipermail/libpqxx-general/2006-July/001360.html) > > and others have experienced. I'd like to get to the point of following > Bart Samwell's advice to use nmake, but unfortunately something else has > gone wrong upstream. After accidentally mucking up the directory, I > re-untarred the postgresql src package, uninstalled postgres packages > from cygwin and PostgreSQL from Windows, rebooted, and started over. > > Now, from a clean src package, I get different behavior from configure. > Formerly, it seemed to build as for win32. I had a spot of trouble the > first time through with the compiler finding src/port/pg_config_paths.h > wile compiling in src/interfaces/ecpg/ecpglib. This problem did not > remanifest. Unfortunately I didn't capture the configure output the one > time it worked, but looking at the output now, configure is using the > cygwin template rather than the win32 one. Make doesn't error; neither > does it produce libpq.dll and Release much less libpqd.dll and Debug. > > Short of a clean machine with a fresh install of cygwin (which I can't > afford to do; other software depends on it in fragile ways), I'm > stumped. Does anyone have any suggestions for getting configure/make to > produce these DLLs? > > I will eventually be compiling libpqxx and then my client program with > MSVC 2005, so if I am barking up the wrong tree altogether, please do > say so :) > > Curran > >
On Mon, 2007-01-08 at 15:19, Curran Schiefelbein wrote: > If this is not the right list for this problem, could someone please > point me to the right area? according to this page: http://www.postgresql.org/community/lists/ "Current win32 development issues should be raised on -hackers. Cygwin issues should be raised on -cgywin." so, one of those. I'm not sure you really want to be building under cygwin, but would be looking for the native windows build.