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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev