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

[Even Rouault]

No problem. That happens quite regularly when adding substantial contributions 
like new drivers that require changes in the build system on the various 
targets. To check if things go well, you can look at the waterfall 
http://buildbot.osgeo.org:8500/waterfall which has different slavebots (Linux 
& Windows ones). Some are triggered at each commit and do an incremental 
build (telascience-quick), others do a full rebuild every few hours. But if 
necessary, you can also ask those ones to do a full rebuild at anytime by 
clicking on the right button.

In case he's not yet aware of it, we have an extensive test suite made of 
Python scripts. It's available there : 
http://svn.osgeo.org/gdal/trunk/autotest (browser view : 
http://trac.osgeo.org/gdal/browser/trunk/autotest/ )

Le Thursday 08 April 2010 00:35:17, vous avez écrit :
> 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.