[postgis-users] Building PostGis with VC++

[Mateusz Loskot]

Charlie Savage wrote:
> 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.

Charlie,

Could you specify what version of Visual C++ you're using?
Just for clarification.

> ------------------------------------------
> 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)
> }

Possible workaround is to compile .c file in C++ mode (use /TP instead
of /TC option).

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

Hmm, could you point where this constant is used?

> * 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.

Visual C++ does not support VLA, so this code is well unsupported by
Microsoft's compiler.

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

Simply, Visual C++ does not support features from addendum to the C
language standard, but only plain C89.

> 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.

Perhaps, pj_errno could be replaced with function pointers, as it errno
global is solved in newer and thread-safe implementations of C library.

extern int* pj_errno_proxy(void);
#define errno (*pj_errno_proxy())

> 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?

IMHO, it sounds as best solution.


p.s. i've taken the liberty to give my 5 cents :-)

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net