[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  |  
---------------------------+------------------------------------------------
Description changed by robe:

Old description:

> 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

New description:

 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

--

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2364#comment:2>
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.