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

Sat Jun 15 20:27:05 PDT 2013

Completing our migration to cmake is definitely a good first step.

However I think the effort involved in building with same chain as EDB might
be a little underestimated.

1) First off - mixing say a VS 2008 C++,  VS 2010 C++ and VS 2012 C++ you
may run into same or more issues
EDB builds PostgreSQL 9.1 with VS 2008 and 9.2, 9.3 with VS 2010 and 9.4
will probably build with VS 2012 

So right there freedom of building for all sets becomes vastly more
complicated as the C++ abi parts are very incompatible
Particularly with 2008/2010 based on my understanding.

For the most part I've avoided these differences simply because the only
dependencies PostGIS shares with 
EDB builds (aside from PostgreSQL) is the libxml and basic C library (which
is part of windows)

And for 32-bit there has never been an issue that didn't turn out to be an
issue with PostGIS code itself.

2) VS 2012 C++ Express is the first version that directly supports 64-bit
building
Others require full professional/enterprise version or (relegated to using
Windows 64-bit SDK) which as I have tried before
Is froth with problems.  Perhaps these have been fixed or I did not do it
right nevertheless it seemed like a huge mess to me.

This makes it difficult to use say on a buildbot (pre-2012) where licensing
can get REALLY expensive.

I will note that PL/R does build with VS because they have to to work with
EDB builds.

http://www.joeconway.com/plr/  (but not sure if they are currently using
professional or express)

3) I think people envision there are lots of C and C++ windows developers
out there and they'd be suddenly interested in helping out If VS is
supported.
Or have Visual C++ readily installed.

  As a windows user, I have never seen one of these creatures that did not
consider themselves primarily a Linux developer.
All pure windows developers I know are C# developers.

So we are talking about supporting a fairly non-existent group as far as I
can tell.

Just in case:
Windows C,C++ developers (who only work on Windows), PLEASE RAISE YOUR HANDS
:)

That said even though I don't develop on Unix nor count myself as a C
developer, I've been able to easily transpose
Solutions from Unix/Linux developers simplify because mingw64 steps aren't
that much different.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at lists.osgeo.org
[mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Saturday, June 15, 2013 7:56 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Windows 64-bit error handling issues Good and
Bad News

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

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel