On Thu, Feb 28, 2013 at 1:20 PM, Andrew Dunstan
<andrew@dunslane.net> wrote:
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?)
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).
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.
If you mean the Linux part, that was built natively, not cross-compiled with Windows. I just needed a "known good" system so that I could try to dissect what was going on by pointing a known good psql to a questionable server, and vice versa.
If you mean on Windows itself, I did get a warning during the ./configure stage:
./configure --host=x86_64-w64-mingw32 --without-zlib >/dev/null
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
I didn't know what it meant and just ignored it.
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?
OK, so it must be a path or environment thing. I'll see if I can figure out exactly what.
Cheers,
Jeff
