[postgis-devel] Windows 64-bit error handling issues Good and Bad News

[Paul Ramsey]

I've been steering wide of all these EDB/64/mingw build issues because they scream "environment" rather than code. I'm looking forward to you finding a platform that produces consistent builds, but it seems to me that the ultimate solution is to build using the same chain as EDB, which means completing our migration to cmake and building with MSVC on windows platforms. (As well as building all our dependencies with the same chain, as well, sigh.) 

P. 

-- 
Paul Ramsey
http://cleverelephant.ca/
http://postgis.net/


On Saturday, 15 June, 2013 at 12:50 PM, Paragon Corporation wrote:

> Sorry for the length of this message but just wanted to get people's
> thoughts on this matter. As some may know I've been battling
> With issues that only appear running postgis in 64-bit mode under PostgreSQL
> EDB installers (they don't show urnning under pure mingw64)
> These issue are isolated to how windows 64-bit handles errors and the
> pattern is an erorr that requires a callback to another function seems to
> often fail with the code just pretending like the error was never raised.
> Issue described
> http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-
> vs-dwarf-vs-seh and
> http://en.wikipedia.org/wiki/Structured_Exception_Handling#Structured_Except
> ion_Handling
> 
> Needless to say my newbie read SHE hadnling for 64-bit windows is preferred,
> but structured error handling is not supported in GCC
> Prior to 4.8.0 release.
> 
> 
> 
> 
> 1) The VERY good news is using Mingw64 GCC 4.8.0 that has structured error
> handling (SEH) as Mark Cave-ayland suggested 
> 
> - (I think what VC++ 2010 and above use windows SEH for 64-bit error
> handling)
> I was able to get PostGIS 2.1.0 to regress cleanly with EDB VC++ builds
> provided PostgreSQL 9.2.4 EDB 64-bit
> 
> (still need to test 9.3 chain)
> Just for reference the regress failures were all triggered by when we
> trigger an error and its only errors that are deep in.
> Basically a function in postgis calls another function that is the one
> triggering the error and the call back 
> 
> http://trac.osgeo.org/postgis/ticket/2338
> 
> http://trac.osgeo.org/postgis/ticket/2339
> 
> 
> The bad news
> 
> 1) My binaries are incompatible with the old PostGIS 2.0 (because of geos
> and gdal that both rely on C++ plumbing) which means I would need to
> release a 2.0 at the same time as 2.1 for those who happened to have both
> 2.0 and 2.1 installed. Given 2.0 has same error handling issues -- its not a
> bad idea
> 
> 2) The other bad news -- not quite as bad, building PostgreSQL under mingw64
> (both 32-bit and 64-bit) 4.8.0 gcc has a nasty little problem that the
> libpq.dll generated errors out when you launch psql
> 
> could not connect to server: Operation would block (0x00002733/10035)
> Is the server running on host "localhost" (::1) and accepting
> 
> though only seems to affect psql. But causes the make check in building
> postgresql to fail.
> 
> This is a known issue that many have complained about 
> http://www.postgresql.org/message-id/E1UcLPd-0000L4-TI@wrigleys.postgresql.o
> rg
> 
> and someone has even provided a patch for even 
> 
> http://www.postgresql.org/message-id/50F9D003.6000805@cybertec.at
> 
> 
> I was able to get around this by swapping out the libpq with my 4.5.4
> compiled psql (and I think even using edb one worked)
> So not a major showstopper. Just puzzling. Only difference I can see is
> the 4.8.0 compile psql has an extra dependency on user32.dll that the 4.5.4
> and edb ones don't and given it affects the 32-bit as well (which doesn't
> use seh), its not seh related and possibly because of this dependency.
> 
> 
> 
> So given that I haven't gotten a chance to really stress test this in the
> field and I think most of the serious error handling issues we've added some
> sand to so people don't slip, I'm tempted to
> 
> 1) Build these binaries for 2.0, 2.1 chain -- but only offer them as
> binaries for people who are running into the issue or would like
> To test them out
> 
> 2) When 2.2 rolls along - standardize on GCC 4.8.0 for windows build (both
> 32 and 64-bit branches) ( and I'll be experimenting with Mat's Cmake build
> path as well now that I'm already successfully building GEOS,pgrouting with
> cmake and partially successful with sfcgal and if brave enough might even
> pull out VC 2012 express to see how well psotgis can really be built and
> tested using cmake).
> 
> 3) Another thought -- since 9.3 is not out, could just build these with
> 4.8.0 gcc (never with 4.5.4) but that complicates my buildbot machinery
> quite a bit since I would need to run 9.3 on a separate mingw build chain
> and rebuild all the dependencies under this mingw. Doable but need much
> config.
> 
> Anyone have an opinion on direction.
> 
> Thanks,
> Regina
> http://www.postgis.us
> http://postgis.net
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org (mailto:postgis-devel at lists.osgeo.org)
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel