[gdal-dev] gdal / ESRI SDE / mapserver

Howard Butler hobu.inc at gmail.com
Tue Jan 20 13:18:16 EST 2009


On Jan 20, 2009, at 10:49 AM, Russell McOrmond wrote:

>
>  As many of you likely already know (and I just found out), there  
> are incompatabilities between ESRI's libsde and the zlib library  
> that many tools we use need.   I can stop the various core dumps by  
> compiling and making available the same version of zlib that is  
> inside libsde (which for ArcSDE 9.2sp5 is zlib 1.1.3).
>
> Notes about the bug here: http://forums.esri.com/Thread.asp?c=2&f=1718&t=212867
>
>
>  Gdal has an internal version of zlib, used when the otherwise  
> provided zlib doesn't have all the functionality needed.  The  
> current configure script includes the include path provided by ./ 
> configure command line parameters before this local zlib directory.   
> This means the wrong zlib.h gets include and the compile complains  
> on the missing function inflateCopy().
>
>  Is it possible for this order to be patched up, or a ./configure  
> line parameter created?  What I am doing currently is renaming the  
> zconf.h and zlib.h out of the way for the build of gdal, renaming  
> back after.
>
>  I am wondering.  Given gdal includes this functionality, I'm  
> wondering if it is possible to export this functionality.  Mapserver  
> needs these functions, and could also be configured to use the gdal  
> version rather than the one provided by zlib.  This might avoid the  
> compatability problems with libsde and zlib -- at least for  
> mapserver and other tools which are built upon gdal.


Russell,

The situation totally sucks and I'm glad that you've been so  
persistent in pushing things through to make it work for you.  When I  
was encountering the problems as I was developing the SDE raster  
driver, my client mainly needed windows where this wasn't a problem.   
I only ran into stuff when testing on my own, and I only went as far  
to hack the makefiles and complain on my weblog and on that ESRI thread.

I think the way forward is if you could document this misery on the  
wiki http://trac.osgeo.org/gdal It's a hard sell for us to complicate  
our already messy configure logic to work around their bug that they  
stubbornly won't fix.  In the end, spending a day or so getting the  
configure logic to work correctly isn't going to be worth it  
considering the few users who need this functionality, and it can be  
obtained with some minor surgery and simple instructions (figuring out  
what parts to cut without killing the patient is the work you did :).   
Especially if the fix is "soon", we'll have to complicate the logic  
even more afterward to deal with versions of this and that.

Please make an ArcSDE wiki page off of http://trac.osgeo.org/gdal/wiki/BuildHints 
  and document the issues and how you resolved them as best you can  
with pertinent version information.  I think that will be the most  
fruitful way forward.

Howard


More information about the gdal-dev mailing list