[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