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

[Francesco P. Lovergine]

On Wed, Apr 07, 2010 at 09:36:31PM +0200, Even Rouault wrote:
> 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 ?
> 

Currently minizip is provided in libkml as a shlib on Debian, but it is not
distributed with zlib. That could change in the future, but currently
there's not a proper support upstream (e.g. no SONAME etc.). The libkml
way is a bit peculiar because google folks have introduced a shared lib
on their own, which is not something provided by Gilles. 

As a general advice, Debian policy discourage embedding of third parties libraries,
because security support becomes a nightmare and we have currently
no way of tracking embedded libraries in the whole archive.

My own opinion is that GDAL should provide both a inner copy and/or a way
of linking an external library. Using a gdal-specific namespace is a
solution for name collisions, but does not solve the security concerns.

> 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)
> 

We (as Debian) could move to use versioned symbols, which
could definitively solve those kind of problems. But that is a GNU ld
specific implementation. Other libraries already adopted the same trick.

> (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.

-- 
Francesco P. Lovergine