On 02/28/2013 11:37 AM, Jeff Janes wrote:
Did you copy libpq.dll from the lib directory to the bin
directory? If not, try that and see if it fixes the problem.
I've now done that, and it did fix the problem. I can start the
database with pg_ctl.exe if I want.
Should the makefile do this for us? Or is there a way to configure so
that is not needed (whatever the MinGW equivalent is to an rpath?)
To the best of my knowledge, there isn't one really. The buildfarm
script has for a long time copied the *pq.dll to the install bin
directory, and added the latter to the PATH. This might be a belt and
braces (that's "suspenders" for Americans) approach, but it's worked for
a long time ;-) There is probably a good case for "make install" to do
this copy on Windows.
psql.exe now runs, but it seems to be broken. It hangs forever on
attempting to connect to any server (either the local one compiled
with MinGW, or a remote server running on Linux).
I have not seen this. When I get a chance I will try to reproduce it.
psql on the remote linux machine can connect back to the Windows
server compiled with MinGW, so the problem seems to be with MinGW's
psql.exe, not its server.
You built this natively, not with a cross-compiler, right?
Doesn't "make check" have to use something which is morally equivalent
to psql.exe? If so, how can it pass if psql.exe is broken?
No, it *uses* psql. If "make check" is working then so is psql. There is
zero chance of it working with a broken psql.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
