Description of problem: $ gcc -x c -include /usr/include/minizip/crypt.h -c - </dev/null In file included from <command-line>:32:0: /usr/include/minizip/crypt.h:35:53: error: unknown type name ‘z_crc_t’ static int decrypt_byte(unsigned long* pkeys, const z_crc_t* pcrc_32_tab) ^~~~~~~ /usr/include/minizip/crypt.h:48:51: error: unknown type name ‘z_crc_t’ static int update_keys(unsigned long* pkeys,const z_crc_t* pcrc_32_tab,int c) ^~~~~~~ /usr/include/minizip/crypt.h:65:69: error: unknown type name ‘z_crc_t’ static void init_keys(const char* passwd,unsigned long* pkeys,const z_crc_t* pcrc_32_tab) ^~~~~~~ This break compilation of software which #includes minizip/crypt.h. Those types are defined in zconf.h, which used to be included in crypt.h. I don't know why minizip dropped that include. Version-Release number of selected component (if applicable): minizip-1.2.11-2.fc26.x86_64
Thanks for the report, this is partly my fault: https://bugzilla.redhat.com/show_bug.cgi?id=985344 (reverted downstream-only, never proposed patch, I don't know why) I'm curious how are you using the header, which is obviously not (yet?) ready to be used "as-is". Can you please specify your use-case?
Note that the crypt.h defines only static methods which are to be included in zip.c/unzip.c. So you could be OK to include only zip.h/unzip.h and link against libminizip.
I noticed because libsbml FTBFS. It turns out that the header was included by mistake: there's a bunch of unrelated crypt.h files, and (although it was supposed to be included in one place) it was also included inadvertently in another place because -I/usr/include/minizip was added to CFLAGS. So in the end, my fix for libsbml was to change #include <unzip.h> to #include <minzip/unzip.h> and remove the -I flag. That said, it's a general rule that headers should pull in all of their own dependencies, so that including them anywhere (and in any order), just works. Most projects I know try to that for all of their .h files, and certainly for any that are installed into publicly visible locations.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > That said, it's a general rule that headers should pull in all of their own > dependencies, so that including them anywhere (and in any order), just > works. Most projects I know try to that for all of their .h files, and > certainly for any that are installed into publicly visible locations. Agreed with this "rule of thumb", it is good idea to have test-suite for this rule, for sure. But we are not upstream and it makes no sense to have maintain downstream patches for this (so it was dropped). What I'm rather thinking about is to not install crypt.h at all, as that seems to be bug anyways (internal headers should be noinst_*).
https://github.com/madler/zlib/pull/229
Looks like we get a breakage in sigil due that, the python header most likely wants /usr/include/crypt.h, but due the build-system the minizip's crypt.h is preferred ... [ 34%] Building CXX object src/CMakeFiles/sigil.dir/main.cpp.o cd /builddir/build/BUILD/Sigil-0.9.9/build/src && /usr/bin/c++ -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS -DQT_WEBKITWIDGETS_LIB -DQT_WEBKIT_LIB -DQT_WIDGETS_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -I/builddir/build/BUILD/Sigil-0.9.9/build/src/sigil_autogen/include -I/builddir/build/BUILD/Sigil-0.9.9/build/src -I/builddir/build/BUILD/Sigil-0.9.9/src -I/builddir/build/BUILD/Sigil-0.9.9/internal/gumbo -I/usr/include/python3.6m -I/usr/include/minizip -I/usr/include/hunspell -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/./mkspecs/linux-g++ -isystem /usr/include/qt5/QtXml -isystem /usr/include/qt5/QtXmlPatterns -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtPrintSupport -isystem /usr/include/qt5/QtSvg -isystem /usr/lib64/qt5/../../include/qt5 -isystem /usr/lib64/qt5/../../include/qt5/QtWebKit -isystem /usr/lib64/qt5/../../include/qt5/QtWebKitWidgets -isystem /usr/include/qt5/QtConcurrent -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -std=c++11 -Wall -fPIC -std=gnu++11 -o CMakeFiles/sigil.dir/main.cpp.o -c /builddir/build/BUILD/Sigil-0.9.9/src/main.cpp In file included from /usr/include/python3.6m/Python.h:39, from /builddir/build/BUILD/Sigil-0.9.9/src/Misc/EmbeddedPython.h:26, from /builddir/build/BUILD/Sigil-0.9.9/src/main.cpp:22: /usr/include/minizip/crypt.h:35:53: error: 'z_crc_t' does not name a type static int decrypt_byte(unsigned long* pkeys, const z_crc_t* pcrc_32_tab) ^~~~~~~ /usr/include/minizip/crypt.h:48:51: error: 'z_crc_t' does not name a type static int update_keys(unsigned long* pkeys,const z_crc_t* pcrc_32_tab,int c) ^~~~~~~ /usr/include/minizip/crypt.h:65:69: error: 'z_crc_t' does not name a type static void init_keys(const char* passwd,unsigned long* pkeys,const z_crc_t* pcrc_32_tab) ^~~~~~~
zlib-1.2.11-7.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c12b8339cd
https://src.fedoraproject.org/rpms/zlib/c/4d2785ec3116947872f6f32dc4104e6d36d8a7a4?branch=master
zlib-1.2.11-7.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c12b8339cd
zlib-1.2.11-7.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.