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

[Even Rouault]

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.