Setup winnie with a mingw64 gcc 4.8.0 seh chain

[robe]

As noted in #2339 switching my mingw64 build chain from gcc 4.5.4 to gcc 4.8.0 fixes all the regression failures when regressing against an EDB 9.3 install.

I'm setting up a separate self-standing install I'll call ming64gcc48 that I'll copy to winnie when I'm done and also make available for download for folks. This is the chain I'll be using to compile 9.3 for final release and moving forward. The only snaffu is the issue with when building PostgreSQL that the libpq.dll make psql not work with:

psql: could not connect to server: Operation would block (0x00002733/10035)
        Is the server running on host "localhost" (::1) and accepting
        TCP/IP connections on port 5443?
could not connect to server: Operation would block (0x00002733/10035)
        Is the server running on host "localhost" (127.0.0.1) and accepting
        TCP/IP connections on port 5443?

and in fact makes the make check for postgresql build fail with:

../../../src/test/regress/pg_regress --inputdir=. --temp-install=./tmp_check --t
op-builddir=../../..   --dlpath=.  --schedule=./parallel_schedule
============== creating temporary installation        ==============
============== initializing database system           ==============
============== starting postmaster                    ==============
make[1]: *** [check] Error 58

I would like to get this issue fixed before I distribute a standalone that people can use. For the time being I can work around the issue by replacing the libpq.dll on the newly built postgres.

In looking over why I don't have this issue with prior 4.5.4 and why its only a complaint of folks running 4.8 (4.7 folks say it worked), I have discovered that gcc 4.8. is a new animal in and of itself and it might be the new stricter changes in 4.8 causing the issue.

​http://gcc.gnu.org/gcc-4.8/changes.html

New gcc conforms to the C++ 11 standard

In particular I was wondering about for example this:

GCC now uses a more aggressive analysis to derive an upper bound for the number of iterations of loops using constraints imposed by language standards. This may cause non-conforming programs to no longer work as expected, such as SPEC CPU 2006 464.h264ref and 416.gamess. A new option, -fno-aggressive-loop-optimizations, was added to disable this aggressive analysis. 

unfortunately sneaking it in like this did not seem to work or perhaps pg configure ignores it

./configure CFLAGS="-fno-aggressive-loop-optimizations ${CFLAGS}" ..

but I suspect I'm just doing this all wrong. I also wanted to try the new 4.8.1, but thought I would hold off on that since I got everything working so well with 4.8.0 and experimenting with 4.8.1 did not fix the above nagging issue