Bundled minizip is used even when system minizip is found

[plaes]

Currently the bundled minizip get included even when the system minizip is found:

[ 80%] Building CXX object src/CMakeFiles/digidocpp.dir/util/ZipSerialize.cpp.o
cd /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src && /usr/bin/c++   -DBUILD_DATE=\"14.08.2015\" -DBUILD_VER=1296 -DDIGIDOCPP_CONFIG_DIR=\"/usr/local/etc/digidocpp\" -DDOMAINURL=\"ria.ee\" -DLINKED_LIBDIGIDOC -DMAJOR_VER=3 -DMINOR_VER=11 -DORG=\"RIA\" -DPKCS11_MODULE=\"opensc-pkcs11.so\" -DRELEASE_VER=0 -DTSA_URL=\"http://tsa.sk.ee\" -DTSL_URL=\"https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml\" -DVER_SUFFIX=\"\" -Ddigidocpp_EXPORTS -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -fPIC -I/var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src -I/usr/include/minizip    -o CMakeFiles/digidocpp.dir/util/ZipSerialize.cpp.o -c /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/util/ZipSerialize.cpp
In file included from /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/minizip/zip.h:54:0,
                 from /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/util/ZipSerialize.cpp:25:
/var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/minizip/ioapi.h:135:51: error:
expected initializer before ‘OF’
 typedef voidpf   (ZCALLBACK *open_file_func)      OF((voidpf opaque, const char* filename, int mode));
                                                   ^

-I/usr/include/minizip is passed in, but bundled minizip is somehow used anyway.

When bundled minizip is deleted (via rm -r src/minizip) build succeeds.

[metsma]

None of our supported systems contains bundled minizip. Our resources are limited but feel free to send pull request for workaround.

[plaes]

'Bundled Minizip' means the files that come with the tarball.

If system minizip is found, it shouldn't use the minizip files in tarball, but currently it does.

[metsma]

Seems like fedora has also packaged minizip and they found workaround https://copr.fedoraproject.org/coprs/mihkel/esteid-epel

[metsma]

Maybe you can alter the include order in CMakeFile.txt right now compiler has c++ -I/var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src -I/usr/include/minizip

and move ${MINIZIP_INCLUDE_DIR} first in list https://github.com/open-eid/libdigidocpp/blob/master/src/CMakeLists.txt#L167

[plaes]

Nice catch, indeed the local source directory is first in the include path and minizip includes are following:

#include <minizip/zip.h>
#include <minizip/unzip.h>

This causes bundled minizip headers to be always included.

Now, bundled minizip/zip.h itself includes "ioapi.h" which seems to get included via -I/usr/include/minizip. And incompatibility between system and bundled headers causes build error.

There's also related (fun) issue with minizip packaging - as minizip.pc sets include path to -I/usr/include/minizip, the includes should instead be:

#include <zip.h>
#include <unzip.h>

But there's also /usr/include/zip.h that belongs to libzip.