[postgis-tickets] [PostGIS] #2364: Setup winnie with a mingw64 gcc 4.8.0 seh chain

[PostGIS]

#2364: Setup winnie with a mingw64 gcc 4.8.0 seh chain
---------------------------+------------------------------------------------
 Reporter:  robe           |       Owner:  robe         
     Type:  task           |      Status:  new          
 Priority:  medium         |   Milestone:  PostGIS 2.1.0
Component:  buildbots      |     Version:  trunk        
 Keywords:  windows64,edb  |  
---------------------------+------------------------------------------------
 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

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2364>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.