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 64-bit 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.3x64 (maybe 9.3 32-bit also since for some reason PL/V8 suffers same issues on 32-bit and i need my libstdc++ for 32-bit for pl/v8 to be same as postgis distributed) 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

[robe]

aha -- and they are even talking about that very switch in this postgresql thread

​http://www.postgresql.org/message-id/14242.1365200084@sss.pgh.pa.us (Back branches vs. gcc 4.8.0)

---

After quite a bit of hair-pulling trying to install Fedora 19 Alpha, I've been able to reproduce the initdb-time failure that's currently being seen on buildfarm member anchovy, and was also complained of recently by an end user: ​http://www.postgresql.org/message-id/CAOD=oQ-kq3Eg5SOvRYOVxDuqibVWC8R0wEivPsMGcyzZY-nfzA@mail.gmail.com

It is exactly what I suspected, namely that gcc 4.8.0 is applying an optimization that breaks our code; the odd thing though is that it's not breaking 9.2 or HEAD, just the older branches.

---

[robe]

Done -- she is now building 9.3x64bit PostGIS 2.1 and 2.2 with gcc 4.8 seh. I still need to recompile boost, cgal to support pgrouting (in 2.1) since the current 9.3 pgrouting I have compiled is incompatible with the 4.8 seh. This I hope to reuse for building sfcgal (in 2.2) so I'll probably go with a newer chain of CGAL than I did with other pgrouting.

I was also insane enough to use a newer msys chain -- ​http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages (msys+7za+wget+svn+git+mercurial+cvs-rev13.7z) which I chose because it came all packaged with svn and git yippee.

Unfortunately that meant I needed to be really careful with my PATH setting to insure the msys libraries were found last since it caused some CreateProcess errors (when I mistakenly had those first in my path). I also decided to use fstabs heavily this time so my carry along ming chain doesn't have to sit on the C drive and projects folder can be moved anywhere.

[robe]

If anyone is interested my new 64-bit build chain is here:

​http://www.bostongis.com/postgisstuff/ming64gcc48.7z

I chose the native 64-bit (not 32-bit cross compile 64-bit), so requires windows 64-bit os to use.