Re: Building on MinGW

On Thu, Feb 28, 2013 at 1:20 PM, Andrew Dunstan <andrew(at)dunslane(dot)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?)
>>
>
> 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?

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?
>>
>
> No, it *uses* psql. If "make check" is working then so is psql. There is
> zero chance of it working with a broken psql.
>

OK, so it must be a path or environment thing. I'll see if I can figure
out exactly what.

Cheers,

Jeff