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

[Tamas Szekeres]

2010/4/7 Even Rouault <even.rouault at mines-paris.org>

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


I've took a crack to add minizip support to the Windows buildslaves and
switch this new driver on, I hope the next build will compile this driver in
the plugins section.

However the desired compilation flags of minizip are not so trivial to me,
is the ZIP64 support enabled by default, should I define further variables?
Do we expect to compile minizip as a library or a dll package? The latter
seems to be controlled by ZEXPORT which is not defined properly on Windows.
(zlib is using explicit definition of the exported functions by using a .def
file and not by __declspec(dllexport))

Do we have auto-tests included along with this driver in order to make sure
the compilation is working?

Best regards,


Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100408/443d0f34/attachment.html