minizip-ng: linking of the OCIO library fails when minizip-ng was already installed via MacPorts

The MacPorts package manager installs the minizip-ng library without the trailing -ng, and similarly leaves the -ng off of the minizip-ng-related cmake modules. Configuring and building leaves things in a state where the includes are found, and the binaries all are compiled, but the linker invocation is inconsistent: the no-ng library name is used when specifying its position in the files to be linked, but earlier, in the linker directive to hide the symbols in the minizip-ng library, the -ng is present again, even though that's the wrong name.

There was already code to handle this in CMakeLists.txt if a particular variable (minizip_LIBRARY) was set, but Findminizip-ng.cmake was not setting it. Shortly I will submit a PR that sets it.

I wonder if #2185 is related. Is it possible that find_package("minizip-ng") would do the right thing with the MacPorts-provided minizip-ng without engaging our Findminizip-ng.cmake package at all? That would be great...

The MacPorts-provided .cmake files are all just plain minizip, not minizip-ng:

/opt/local/lib/cmake/minizip/minizip-config-version.cmake
/opt/local/lib/cmake/minizip/minizip-config.cmake
/opt/local/lib/cmake/minizip/minizip-macports.cmake
/opt/local/lib/cmake/minizip/minizip.cmake

and

/opt/local/lib/pkgconfig/minizip.pc

so it's hard to see how any call to find_package("minizip-ng") would do anything useful for us. But I'm new at this; maybe I am missing something. It just seemed to me very odd that src/OpenColorIO/CMakeLists.txt would be willing to check the value of minizip-ng_LIBRARY when nothing else, at least in the cmake-related files we ship, actually seemed to set that variable.

Thoughts?

I am not a CMake expert by any means, but my understanding is, find_package supports two different methods of finding packages -- the classic Module mode, and the modern Config mode:

Config files are instruction sets created and maintained upstream by the library's developers and installed alongside the library. They reliably define all paths and targets.
Find modules are heuristic scripts provided by CMake or downstream consumer projects. They use commands like find_library() to guess locations when a config file is missing.

find_package() tries the module first, then falls back to the config file method (or vice-versa depending on the call), utilizing both as alternative ways to integrate external dependencies.

So, by using find_package("minizip-ng"), the hope is that the minizip-config.cmake file that gets installed does all the heavy lifting, and we can migrate away from maintaining our own Find modules for all dependencies whose developers are using modern CMake conventions, like minizip-ng's are.

Is there a capability I'm not seeing that would have find_package("foo-X") first search for foo-X-config.cmake and then if that doesn't work, retrench and strip off the -X and search for foo-config.cmake? Because I agree that you could probably get things to work that way. But failing that I don't see how (setting suffixes aside) the fundamental issue of minizip-ng installing itself with the name minizip, but our looking for names starting with the longer string minizip-ng, is going to succeed. Maybe I'm just not getting enough sleep.

I'm sorry for the confusion, Joseph, your intuition is correct. If minizip-ng is installed in compatibility mode (with -DMZ_COMPAT=ON, so minizip-ng is disguised as minizip), find_package(minizip-ng) won't find what it's looking for.

I was more remarking on whether maintaining Findminizip-ng.cmake at all is worth the tech debt, now that minizip-ng installs CMake configs.

That said, we seem to be doing a lot of work in Findminizip-ng.cmake to support linking compatibility-mode-minizip-ng... it's not immediately clear to me if it only works for static minizip.a libraries, or if it intentionally cannot find dynamic compat-mode-minizip-ng, as doing so has deployment stability implications for downstream consumers... although I can see the appeal for something like MacPorts, where deployments are always local, and rpaths can be fixed.

I think we should either fix this and guard against automatically finding and linking dynamic compat-mode-minizip-ng by default (e.g., in #2214, maybe we can just change the conditional to if(minizip-ng_COMPAT AND minizip-ng_LIBRARY)), or we should simply explicitly require minizip-ng, and disallow compat-mode-minizip-ng altogether.

I think we'll need to discuss this at a TSC meeting.

Either way, I think the path of least resistance might be to have OCIO's own build system handle the building of the dependencies it needs with -DOCIO_INSTALL_EXT_PACKAGES=ALL, and un-requiring MacPorts' own port:minizip-ng from the build recipe, if you can.

I'm encountering what I believe to be a similar issue. Finding CMake packages is a pain at the best of times, and the minizip/minizip-ng situation isn't a great one either. I'll look into it a little further on my end.

FAILED: [code=1] src/apps/ocioarchive/ocioarchive 
: && /usr/local/bin/c++ -O3 -pipe -ffat-lto-objects -fPIC  -flto=auto -flto=auto -O3 -DNDEBUG -flto=auto -fno-fat-lto-objects -flto=auto -fuse-ld=mold -Wl,--dependency-file=src/apps/ocioarchive/CMakeFiles/ocioarchive.dir/link.d src/apps/ocioarchive/CMakeFiles/ocioarchive.dir/main.cpp.o -o src/apps/ocioarchive/ocioarchive  -Wl,-rpath,/usr/local/tmp/crew/opencolorio.20251123092718.dir/builddir/src/OpenColorIO:  src/apputils/libapputils.a  src/OpenColorIO/libOpenColorIO.so.2.5.0  ext/dist/lib64/libminizip-ng.a  ext/dist/lib64/libpystring.a  /usr/local/lib64/libz.so && cd /usr/local/tmp/crew/opencolorio.20251123092718.dir/builddir/src/apps/ocioarchive && /usr/local/bin/strip /usr/local/tmp/crew/opencolorio.20251123092718.dir/builddir/src/apps/ocioarchive/ocioarchive
In function ‘mz_stream_mem_set_size’,
    inlined from ‘mz_stream_mem_seek’ at /usr/local/tmp/crew/opencolorio.20251123092718.dir/builddir/ext/build/libminizip-ng/src/minizip-ng_install/mz_strm_mem.c:174:15,
    inlined from ‘mz_zip_entry_write_header.constprop’ at /usr/local/tmp/crew/opencolorio.20251123092718.dir/builddir/ext/build/libminizip-ng/src/minizip-ng_install/mz_zip.c:888:19:
/usr/local/tmp/crew/opencolorio.20251123092718.dir/builddir/ext/build/libminizip-ng/src/minizip-ng_install/mz_strm_mem.c:62:9: warning: ‘__builtin_memcpy’ writing between 18446744071562067968 and 18446744073709551615 bytes into a region of size 0 [-Wstringop-overflow=]
   62 |         memcpy(new_buf, mem->buffer, mem->size);
      |         ^
/usr/local/tmp/crew/opencolorio.20251123092718.dir/builddir/ext/build/libminizip-ng/src/minizip-ng_install/mz_strm_mem.c:57:26: note: destination object of size 0 allocated by ‘malloc’
   57 |     new_buf = (uint8_t *)malloc((uint32_t)new_size);
      |                          ^
mold: error: undefined symbol: zng_inflateEnd
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans1.ltrans.o:(mz_stream_zlib_close)
mold: error: undefined symbol: zng_crc32
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans0.ltrans.o:(mz_zip_reader_entry_read)
mold: error: undefined symbol: zng_inflate
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans1.ltrans.o:(mz_stream_zlib_read)
mold: error: undefined symbol: zng_deflateEnd
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans1.ltrans.o:(mz_stream_zlib_close)
mold: error: undefined symbol: zng_inflateInit2
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans1.ltrans.o:(mz_stream_zlib_open)
mold: error: undefined symbol: zng_deflate
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans1.ltrans.o:(mz_stream_zlib_write)
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans1.ltrans.o:(mz_stream_zlib_close)
mold: error: undefined symbol: zng_deflateInit2
>>> referenced by <artificial>
>>>               /usr/local/tmp/ccbbpsGC.ltrans1.ltrans.o:(mz_stream_zlib_open)
collect2: error: ld returned 1 exit status
[516/529] Building CXX object src/bindings/python/CMakeFiles/PyOpenColorIO.dir/PyTypes.cpp.o

I'm fairly sure that my clumsiness with git in dealing with the PR being more than a thousand commits behind upstream ended up making this PR horribly mangled. Will close this, delete the branch, and start over ... in a bit.

@Zopolis4

@Zopolis4 , closing this was an error on my part, I had intended to close a Frankenstinian MacPorts PR. Never work with GitHub when one is really really short on sleep. I will pick this topic up again, because it's still legitimately troublesome, in a day or two, in a new issue.

Navigation Menu

Repository navigation

minizip-ng: linking of the OCIO library fails when minizip-ng was already installed via MacPorts #2213

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

minizip-ng: linking of the OCIO library fails when minizip-ng was already installed via MacPorts #2213

Description

Activity

zachlewis commented on Oct 28, 2025

JGoldstone commented on Nov 3, 2025

zachlewis commented on Nov 3, 2025

JGoldstone commented on Nov 4, 2025

zachlewis commented on Nov 4, 2025

Zopolis4 commented on Nov 23, 2025

JGoldstone commented on Nov 24, 2025

JGoldstone commented on Nov 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions