I just checked the link and seems like the build is broken on szekerest-vc80-full. It cannot find ioapi.h which should be present in minizip include directory. I compiled the minizip as a library. Below are the commands I used in order to build minizip in VS2005 Command Prompt:
@echo off setlocal enableextensions enabledelayedexpansion set MSVCPLATFORM=win32 set THIRDLIB=C:\sdk set MINIZIPDIR=%THIRDLIB%\minizip set DEBUGDIR=debug set RELEASEDIR=release vcbuild /rebuild /useenv /platform:%MSVCPLATFORM% minizip.vcproj "Debug" vcbuild /rebuild /useenv /platform:%MSVCPLATFORM% minizip.vcproj "Release" xcopy /I /Y /C /Q src\*.h %MINIZIPDIR%\include xcopy /I /S /Y /C /Q %DEBUGDIR%\minizipd.lib %MINIZIPDIR%\lib xcopy /I /S /Y /C /Q %RELEASEDIR%\minizip.lib %MINIZIPDIR%\lib endlocal I will add auto-tests for this driver soon. Regards, Harsh Govind ________________________________________ From: Tamas Szekeres [[email protected]] Sent: Wednesday, April 07, 2010 06:16 PM To: Even Rouault Cc: Harsh Govind; [email protected] Subject: Re: [gdal-dev] GDAL trunk compilation broken by r19335 / minizip / libkml 2010/4/7 Even Rouault <[email protected]<mailto:[email protected]>> (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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
