Should the 2023 aswf-docker container images include minizip-ng 4.0.10?

[jfpanisset]

The 2023.3 aswf-docker container images have minizip-ng 3.0.10, where mz.h contains an invalid hex constant:

#define MZ_VERSION_BUILD                (03000a)

which breaks code in OCIOZArchive.cpp starting with OCIO 2.3.x:

#if MZ_VERSION_BUILD >= 040000

minizip-ng 4.0.10, included in the 2024 / 2025 / 2026 images fixes that:

#define MZ_VERSION_BUILD (0x04000A)

Some CI permutations in other projects want to build OCIO 2.3.x in the 2023.3 images. Would it be an issue for OCIO if 2023 images moved to minizip-ng 4.0.10?

[doug-walker]

@jfpanisset , I don't think it would be an issue for OCIO if you raise the minizip-ng version in that container.

[lgritz]

I'm seeing this issue in broken 2023 containers for OSL as well -- because OSL has to build OIIO, and OIIO has to build OCIO, and OCIO breaks with the minizip-ng in the container.

[jfpanisset]

I was hoping that a simple hack like:

sed -i 's/03000a/0x03000A/' /usr/local/include/mz.h

would be enough to allow OCIO 2.3.2 to build against minizip-ng 3.0.10, but it seems like this code in OCIOZArchive.cpp:

#if MZ_VERSION_BUILD >= 040000
    write_mem_stream = mz_stream_mem_create();
#else
    mz_stream_mem_create(&write_mem_stream);
#endif

isn't really doing what it thinks it is doing, it would need to be something like:

#if MZ_VERSION_BUILD >= 0x040000
    write_mem_stream = mz_stream_mem_create();
#else
    mz_stream_mem_create(&write_mem_stream);
#endif

The following patch kinda makes this work, but of course it requires a patched version of mz.h 3.0.10 with a correct hex constant (the sed line above):

cat << 'EOF' | patch -p1
diff --git a/src/OpenColorIO/OCIOZArchive.cpp b/src/OpenColorIO/OCIOZArchive.cpp
index d99dd79ac..bfda2778a 100644
--- a/src/OpenColorIO/OCIOZArchive.cpp
+++ b/src/OpenColorIO/OCIOZArchive.cpp
@@ -226,7 +226,7 @@
     std::string configStr = ss.str();

     // Write zip to memory stream.
-#if MZ_VERSION_BUILD >= 040000
+#if MZ_VERSION_BUILD >= 0x040000
     write_mem_stream = mz_stream_mem_create();
 #else
     mz_stream_mem_create(&write_mem_stream);
@@ -242,7 +242,7 @@
     options.compress_level  = ArchiveCompressionLevels::BEST;

     // Create the writer handle.
-#if MZ_VERSION_BUILD >= 040000
+#if MZ_VERSION_BUILD >= 0x040000
     archiver = mz_zip_writer_create();
 #else
     mz_zip_writer_create(&archiver);
@@ -341,7 +341,7 @@
     std::string outputDestination = pystring::os::path::normpath(destination);

     // Create zip reader.
-#if MZ_VERSION_BUILD >= 040000
+#if MZ_VERSION_BUILD >= 0x040000
     extracter = mz_zip_reader_create();
 #else
     mz_zip_reader_create(&extracter);
@@ -463,7 +463,7 @@
     std::vector<uint8_t> buffer;

     // Create the reader object.
-#if MZ_VERSION_BUILD >= 040000
+#if MZ_VERSION_BUILD >= 0x040000
     reader = mz_zip_reader_create();
 #else
     mz_zip_reader_create(&reader);
@@ -527,7 +527,7 @@
     void *reader = NULL;

     // Create the reader object.
-#if MZ_VERSION_BUILD >= 040000
+#if MZ_VERSION_BUILD >= 0x040000
     reader = mz_zip_reader_create();
 #else
     mz_zip_reader_create(&reader);
diff --git a/src/apps/ocioarchive/main.cpp b/src/apps/ocioarchive/main.cpp
index d99dd79ac..bfda2778a 100644
--- a/src/apps/ocioarchive/main.cpp
+++ b/src/apps/ocioarchive/main.cpp
@@ -235,7 +235,7 @@
         }

         std::string path = args[0];
-#if MZ_VERSION_BUILD >= 040000
+#if MZ_VERSION_BUILD >= 0x040000
         reader = mz_zip_reader_create();
 #else
         mz_zip_reader_create(&reader);
EOF

[jfpanisset]

In general library projects really need to think about the versioning scheme they will be using up front, and make sure it is robust enough not to have to change in the future...