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 [[email protected]] Sent: Wednesday, April 07, 2010 03:36 PM To: Harsh Govind Cc: [email protected]; [email protected]; Frank Warmerdam; [email protected] 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. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
