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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
