[postgis-users] Building PostGis with VC++

[Charlie Savage]

To track down a bug I was seeing in PostGIS on Windows, I took the time 
to build postgresql, postgis and geos using VC++ (the mingw/gdb combo 
really doesn't cut it for debuggin).  It took about a day to port 
PostGis - the details are below.

I'd be happy to feed this back into the community if there is any 
interest. If there is, should I submit my changes as patches, in the bug 
tracking system, or just commit them (not sure if I have commit access 
to postgis, are permissions shared with geos)?

Note there is one major issue however that needs to be fixed in proj4's 
api - see details below - that I would need help from Frank or others on.

Last - if this doesn't seem that interesting, remember that the 
postgresql group has been spending a fair bit of time in the 8.3 release 
cycle improving postgresql's MSVC++ support.  So I'd expect at least a 
fair number of people to start using it for postgresql due to the pain 
of using mingw/msys.

Thanks,

Charlie

------------------------------------------
Getting PostGis to compile required a combination of various things.

First of course a few twiddling code changes:

* Fix variable initialization issues that GCC allows but VC++ doesn't:

some_method()
{
   if (...)
   {}

   int foo = 7;  <--- This is no go with V++, foo must be declared above)
}

* Move various #defines into config.h (POSTGIS_VERSION, etc.) - I just 
created config.h.vc

* VC++ thought MAX_FLOAT was too big (3.40282347e+38F versus 
3.402823466e+38F)

* The method createTree must use some GCC magic to initialize a variable 
sized array:

         RTREE_NODE *nodes[pointArray->npoints];

That has to be done via malloc/free on Windows.


Second was reimplementing various functions not on widows (rint in 
particular) and a few header files (inttypes.h, etc.)

Third - and the big issue - the interface with proj4 needs to be fixed. 
  On windows, its a no-no to mess with other dll's memory.  Postgis 
accesses two global variables exposed by proj4.  This works ok if you 
statically link to the proj4 library but not if you try to use the 
proj4.dll.

The first issue is pj_release.  That was easily fixed by using 
pj_get_release() instead.

However, the one I couldn't solve was pj_errno.  In one place the 
postgis code doesn't try to initialize it.  Of course proj4 does, so to 
proj4 its zero, to postgis is a random number.  Thus postgis thinks that 
proj4 *always* fails when calling transform.  In a second place, postgis 
does try to initialize pj_errno which causes a segmentation fault.

The solution is to expose a function pj_get_errno() or some such in 
proj4.  There actually is such a beast but it returns a pointer to the 
errno, not the errno, so it doesn't work as is.  Can we just change this 
method to return the errno instead?  Will this break existing clients? 
If so, can we addd a new function to the api?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20070828/95f955b6/attachment.bin>