[gdal-dev] RE: GDAL trunk compilation broken by r19335 / minizip / libkml

[Harsh Govind]

My first commit and build failure. :( Sorry team. I have reverted my changes to GDALmake.opt.in so the build should be fixed. Is there a way to sign up for these build results so as to get an email if your commit breaks the build? I am going to setup an automated build system on windows to cont. build and do some basic testing.

Even,
Thanks for letting me know. I think the KMLSUPEROVERLAY should be added as a OPT_GDAL_FORMATS so it is configurable and user can specify minizip inc/lib. Being a windows guy I could definitely use some help on that side. It will still leave some of the problems you have described. I will do some more research into this problem and possible solutions..

Regards,
Harsh Govind
________________________________________
From: Even Rouault [even.rouault at mines-paris.org]
Sent: Wednesday, April 07, 2010 03:36 PM
To: Harsh Govind
Cc: rush at winkey.org; frankie at debian.org; Frank Warmerdam; gdal-dev at lists.osgeo.org
Subject: GDAL trunk compilation broken by r19335 / minizip / libkml

Harsh,

The telascience (Linux) slavebot fails building latest trunk with :

kmlsuperoverlaydataset.cpp:12:17: error: zip.h: No such file or directory
kmlsuperoverlaydataset.cpp: In function 'bool
...

Full log here :
http://buildbot.osgeo.org:8500/builders/telascience-quick/builds/358/steps/make/logs/stdio

I guess this is because the new driver has a dependency to minizip ? For the
time being, it should probably be removed from GDALmake.opt.in to avoid build
failures.

For the long term solution, I'm not sure what the best option is. In the past,
I had 'imported' the unzip part of minizip in GDAL port subdirectory to add
support for a /vsizip virtual file system. To avoid issues for applications
that would link both GDAL and minizip (see (1)), I had renamed the symbols of
the imported files with cpl_ prefix. I choosed this because as far as I
remember, minizip didn't come as a nicely & standard packaged library (it was
some tool/demonstration code living in the contrib directory from the 'zip'
project) and so it didn't seem practical to add support for its detection
in ./configure (see (2)). Perhaps this has changed now and minizip is a more
standard library dependency. A bit of googling shows
http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/c82c7d7ead3ec189?tvc=2
which reveals that the issue still seems up-to-date. Fedora has apparently
minizip packaged as a library, but Debian not.

The issue with minizip will also arise with the new KML driver that Brian Case
is developping that uses libkml, and minizip is a dependency of libkml. I'm
not sure how libkml is supposed to be packaged : are minizip symbols
statically linked in libkml (if it is the case, are the minizip symbols
exported in the windows/linux builds ?) or is minizip a dependency as a
shared library ?

Actually, another bit of googling shows that Debian has packaged libkml
(http://packages.debian.org/squeeze/libkml0) and that a libminizip.so is part
of the package. But the -dev package doesn't seem to include the headers of
minizip, so it is probably only seen as an internal dependency.

The situation is quite confusing, isn't it ? Any thought anyone on the best
approach to use minizip ?

Best regards,

Even

(1) : This can be a problem. For example some applications use GDAL built with
its internal libtiff (libtiff 4.x based) and also link with the system
libtiff (in most cases still libtiff 3.x), directly or indirectly (for
example GTK+-2.0 links with libtiff). So a guy linking its app with GDAL and
GTK can end up pulling 2 libtiff versions... Because of the ABI changes
between libtiff 3.x and 4.x, this is known to cause crashes on Linux in some
circumstances. We probably want to avoid such situation with minizip in case
various software packages depend on incompatible minizip versions (although
note (2) shows that they've managed to avoid ABI clashes, so this is just a
theoretical problem for now)

(2) : It also enabled me to experiment with adding support for ZIP64
unzipping. Very recently (15 march 2010) upstream zlib has incorporated back
the changes in minizip 1.1 (and in zlib124 package) in a cleaner & backward
compatible way by adding new symbols with 64 prefix. So if latest minizip was
a dependency, we could drop the cpl_minizip files from GDAL source and use
upstream version instead. The ZIP64 issue isn't terribly important to me so
this would certainly not be a show-stopper for moving to another solution
that would only require using the old minizip interfaces. And the
cpl_vsil_gzip.cpp code could certainly be adapted to work with classic or
zip64 symbols according to what is available.