Thread: Building on MinGW
Changed subject from "Strange Windows problem, lock_timeout test request"
On Thu, Jan 24, 2013 at 11:41 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
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.
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?
I've put up a wiki page:
https://wiki.postgresql.org/wiki/Building_With_MinGW
Cheers,
Jeff
On Thu, Jan 24, 2013 at 11:41 AM, Andrew Dunstan <andrew@dunslane.net> 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.
On 01/24/2013 01:44 PM, Jeff Janes wrote:On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan <andrew@dunslane.net> wrote:On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:I've used this description, skipping the Amazon part and putting it
A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment sufficient to build a bare
bones PostgreSQL from scratch is both cheap and fairly easy. The
improvements that mingw has made in its install process, and the presence of
cheap or free windows instances in the cloud combine to make this pretty
simple. But since it's still slightly involved here is how I constructed
one such this morning:
directly on my Windows computer, and it worked.
Except bin/pg_ctl does not work. It just silently exits without doing
anything, so I have to use bin/postgres to start the database (which
is what "make check" uses anyway, so not a problem if you just want
make check). Is that just me or is that a known problem? I've seen
some discussion from 2004, but didn't find a conclusion.
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.
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?
I've put up a wiki page:
https://wiki.postgresql.org/wiki/Building_With_MinGW
Cheers,
Jeff
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
Hello, Jeff. You wrote: JJ> Changed subject from "Strange Windows problem, lock_timeout test request" JJ> On Thu, Jan 24, 2013 at 11:41 AM, Andrew Dunstan <andrew@dunslane.net> wrote: JJ> On 01/24/2013 01:44 PM, Jeff Janes wrote: JJ> On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan <andrew@dunslane.net> wrote: JJ> On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote: JJ> A long time ago I had a lot of sympathy with this answer, but these days not JJ> so much. Getting a working mingw/msys environment sufficient to build a bare JJ> bones PostgreSQL from scratch is both cheap and fairly easy. The JJ> improvements that mingw has made in its install process, and the presence of JJ> cheap or free windows instances in the cloud combine to make this pretty JJ> simple. But since it's still slightly involved here is how I constructed JJ> one such this morning: JJ> I've used this description, skipping the Amazon part and putting it JJ> directly on my Windows computer, and it worked. JJ> Except bin/pg_ctl does not work. It just silently exits without doing JJ> anything, so I have to use bin/postgres to start the database (which JJ> is what "make check" uses anyway, so not a problem if you just want JJ> make check). Is that just me or is that a known problem? I've seen JJ> some discussion from 2004, but didn't find a conclusion. JJ> Did you copy libpq.dll from the lib directory to the bin JJ> directory? If not, try that and see if it fixes the problem. JJ> I've now done that, and it did fix the problem. I can start the JJ> database with pg_ctl.exe if I want. JJ> Should the makefile do this for us? Or is there a way to JJ> configure so that is not needed (whatever the MinGW equivalent is to an rpath?) JJ> psql.exe now runs, but it seems to be broken. It hangs forever JJ> on attempting to connect to any server (either the local one JJ> compiled with MinGW, or a remote server running on Linux). JJ> psql on the remote linux machine can connect back to the Windows JJ> server compiled with MinGW, so the problem seems to be with JJ> MinGW's psql.exe, not its server. JJ> Doesn't "make check" have to use something which is morally JJ> equivalent to psql.exe? If so, how can it pass if psql.exe is broken? JJ> I've put up a wiki page: JJ> https://wiki.postgresql.org/wiki/Building_With_MinGW Jeff, I think inromation about installing dependencies should be added to this Wiki. At least zlib and openssl are "must have" for libpq, psql and pg_dump\pg_restore JJ> Cheers, JJ> Jeff -- With best wishes,Pavel mailto:pavel@gf.microolap.com
On Mon, Mar 4, 2013 at 1:32 AM, Pavel Golub <pavel@microolap.com> wrote:
Hi Pavel,
That would be a good idea, but alas I have no idea how to do those things. For anyone who does know, I would invite you to add those instructions to the wiki. I made the Wiki page only because I grew tired of searching the archives for Andrew's instructions, not because I am an expert on the topic.
Thanks,
Jeff
JJ> I've put up a wiki page:
JJ> https://wiki.postgresql.org/wiki/Building_With_MinGW
Jeff, I think inromation about installing dependencies should be added
to this Wiki. At least zlib and openssl are "must have" for libpq, psql and
pg_dump\pg_restore
Hi Pavel,
That would be a good idea, but alas I have no idea how to do those things. For anyone who does know, I would invite you to add those instructions to the wiki. I made the Wiki page only because I grew tired of searching the archives for Andrew's instructions, not because I am an expert on the topic.
Thanks,
Jeff
On Thu, Feb 28, 2013 at 1:20 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
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.
OK, so it must be a path or environment thing. I'll see if I can figure out exactly what.
Cheers,
Jeff
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.
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?)I have not seen this. When I get a chance I will try to reproduce it.
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).You built this natively, not with a cross-compiler, right?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.
No, it *uses* psql. If "make check" is working then so is psql. There is zero chance of it working with a broken psql.
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
On 03/04/2013 04:12 PM, Jeff Janes wrote: > 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. > This is completely normal. See for example <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=jacana&dt=2013-03-04%2006%3A02%3A01&stg=configure> cheers andrew