The internal Zlib module name changed again in Qt6.6

[the-exodus]

They appear to have a hard time deciding what to name the poor thing, but this will make sure it builds with Qt6.6.1+.

[Neustradamus]

@stachenov: Have you seen this PR?

[stachenov]

Lately, I don't have time and strength to maintain this anymore. I would really welcome it if someone just took over.

It's initially was developed for my previous job, where I had a lot of C++/Qt code, and I needed something to work with ZIP files. And I was young and had nothing to do :-)

But now I'm working exclusively with Java and Kotlin, so maintaining a C++ project on a side became a burden. I have to set up Qt, compilers, CMake, VMs... And I'm no longer young, married, moved to another country, and have my hands full with a lot of stuff.

[cen1]

@stachenov perhaps opening an issue for a call to action is a good idea and then tag all contributors who submitted a patch in the last year or two, maybe people can spare a few hours a month to help maintain. It feels like this project is maintainable with a few days/month effort going by MRs and issues opened. I am only using this lib in one of my projects but it is fundamental and it'd be a shame if it was abandoned.

Personally, I could probably review anything build related, however my C++ is weak, so stuff like MR 177 for example I'd really need to dig in and understand the consequences of the change. Consider this a half-hearted offer to help. :)

[stachenov]

Finally opened an issue for a new maintainer, #185.

[cen1]

Writing a test to cover this before merging.

I am thinking whether we should terminate early with CMake if QUAZIP_USE_QT_ZLIB is set but not found. Right now this setting is more of a "prefer" and just silently warns and finds a system zlib instead. Thoughts?

[the-exodus]

Writing a test to cover this before merging.

I am thinking whether we should terminate early with CMake if QUAZIP_USE_QT_ZLIB is set but not found. Right now this setting is more of a "prefer" and just silently warns and finds a system zlib instead. Thoughts?

Personally I'm always a big fan of early termination on errors. Saves time and makes cleanup simpler.

[cen1]

This looks ok on my local testing. CI testcase taking a bit longer because the github action plugin we use does not support installing Qt with -qt-zlib config option, therefore I'll probably have to prepare specialized containers with Qt >6.6.1 and <6.6.1 built from source to use in the pipeline.

[cen1]

@the-exodus it seems there is still an issue if using -DQUAZIP_ENABLE_TESTS=ON.

/usr/bin/c++ -O3 -DNDEBUG CMakeFiles/qztest.dir/qztest_autogen/mocs_compilation.cpp.o CMakeFiles/qztest.dir/qztest.cpp.o CMakeFiles/qztest.dir/testjlcompress.cpp.o CMakeFiles/qztest.dir/testquachecksum32.cpp.o CMakeFiles/qztest.dir/testquagzipfile.cpp.o CMakeFiles/qztest.dir/testquaziodevice.cpp.o CMakeFiles/qztest.dir/testquazip.cpp.o CMakeFiles/qztest.dir/testquazipdir.cpp.o CMakeFiles/qztest.dir/testquazipfile.cpp.o CMakeFiles/qztest.dir/testquazipfileinfo.cpp.o CMakeFiles/qztest.dir/testquazipnewinfo.cpp.o CMakeFiles/qztest.dir/qztest_autogen/EWIEGA46WW/qrc_qztest.cpp.o -o qztest  -Wl,-rpath,/home/me/qt-everywhere-src-6.6.2/qtbase/lib:/home/me/quazip/build/quazip /home/me/qt-everywhere-src-6.6.2/qtbase/lib/libQt6Network.so.6.6.2 /home/me/qt-everywhere-src-6.6.2/qtbase/lib/libQt6Test.so.6.6.2 ../quazip/libquazip1-qt6.so.1.4 /home/me/qt-everywhere-src-6.6.2/qtbase/lib/libQt6Core5Compat.so.6.6.2 /home/me/qt-everywhere-src-6.6.2/qtbase/lib/libQt6Core.so.6.6.2 /usr/lib/x86_64-linux-gnu/libbz2.so 

/usr/bin/ld: CMakeFiles/qztest.dir/testquagzipfile.cpp.o: in function `TestQuaGzipFile::read()':
testquagzipfile.cpp:(.text+0x8e): undefined reference to `z_gzopen'
/usr/bin/ld: testquagzipfile.cpp:(.text+0xa5): undefined reference to `z_gzwrite'
/usr/bin/ld: testquagzipfile.cpp:(.text+0xad): undefined reference to `z_gzclose'
/usr/bin/ld: CMakeFiles/qztest.dir/testquagzipfile.cpp.o: in function `TestQuaGzipFile::write()':
testquagzipfile.cpp:(.text+0x566): undefined reference to `z_gzopen'
/usr/bin/ld: testquagzipfile.cpp:(.text+0x57d): undefined reference to `z_gzread'
/usr/bin/ld: testquagzipfile.cpp:(.text+0x5b4): undefined reference to `z_gzclose'
/usr/bin/ld: ../quazip/libquazip1-qt6.so.1.4: undefined reference to `z_gzflush'
/usr/bin/ld: ../quazip/libquazip1-qt6.so.1.4: undefined reference to `z_gzdopen'
collect2: error: ld returned 1 exit status

Initialy I noticed it is not being set in the test library var so tried to add:

set(QUAZIP_TEST_QT_LIBRARIES ${QUAZIP_TEST_QT_LIBRARIES} Qt${QUAZIP_QT_MAJOR_VERSION}::${QUAZIP_QT_ZLIB_COMPONENT})

But still nothing. I see other Qt deps linked but not zlib with make VERBOSE=1

If Qt is configured with -qt-zlib the only lib I can find is libQt6BundledZLIB.a which is searched by FindWrapZLIB.cmake. Confusion. Could not decypher from Qt sources if this links to ZlibPrivate or not.

Simply throwing the absolute path of libQt6BundledZLIB.a into target_link_libraries before (order matters) QuaZip::QuaZip makes things work so there must be a CMake issue with Qt6::ZlibPrivate somehow not producing the necessary link. Interestingly enough, quazip module compiles fine if tests are disabled, I will try to compare verbose outputs to see what's going on there.

Ideas welcome.

[cen1]

See also: #186

[the-exodus]

I'm afraid I haven't had Qt installed for several months, and I don't quite have the time to get things set up now.

I'll see if I can look through the logs you pasted and some cmake stuff soon.