Shared library build failure on macOS

[carlocab]

I encountered a build failure for the shared library on macOS Big Sur 11.2.3. CMake was invoked as

==> cmake . -DIconv_IS_BUILT_IN=on -DMZ_FETCH_LIBS=OFF -DBUILD_SHARED_LIBS=ON -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/minizip-ng/3.0.1 -DCMAKE_INSTALL_LIBDIR=lib -DCMAKE_BUILD_TYPE=Release -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DCMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

(Most of these flags are boilerplate that Homebrew adds to assist in building other packages.)

The error I'm getting is

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      _mz_os_utf8_string_create in mz_os_posix.c.o
  "_iconv_close", referenced from:
      _mz_os_utf8_string_create in mz_os_posix.c.o
  "_iconv_open", referenced from:
      _mz_os_utf8_string_create in mz_os_posix.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libminizip.3.0.1.dylib] Error 1
make[1]: *** [CMakeFiles/minizip.dir/all] Error 2
make: *** [all] Error 2

I guess the issue is that CMake hasn't been configured to link with the system libiconv, but I haven't worked out how to get it to do this.

Thanks for any help.

[nmoinvaz]

It should work if you remove -DIconv_IS_BUILT_IN=on. CMake should detect if it is built-in or not. Otherwise you will probably have to also supply Iconv_INCLUDE_DIRS, Iconv_LIBRARY_DIRS, and Iconv_LIBRARIES yourself.

[carlocab]

Hm, yes, omitting that did work. Strangely enough, detecting iconv failed:

-- Performing Test Iconv_IS_BUILT_IN
-- Performing Test Iconv_IS_BUILT_IN - Failed

However, the library still managed to link with it:

❯ otool -L libminizip.3.0.1.dylib
libminizip.3.0.1.dylib:
        /usr/local/opt/minizip-ng/lib/libminizip.3.0.dylib (compatibility version 3.0.0, current version 3.0.1)
        /usr/lib/libcompression.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
        /usr/local/opt/xz/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.5.0)
        /usr/local/opt/zstd/lib/libzstd.1.dylib (compatibility version 1.0.0, current version 1.4.9)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59754.60.13)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

This might be because even though the detection failed, MZ_ICONV was still enabled:

-- The following features have been enabled:

 * MZ_COMPAT, Enables compatibility layer
 * MZ_BZIP2, Enables BZIP2 compression
 * MZ_LZMA, Enables LZMA & XZ compression
 * MZ_ZSTD, Enables ZSTD compression
 * MZ_LIBCOMP, Enables Apple compression
 * MZ_PKCRYPT, Enables PKWARE traditional encryption
 * MZ_WZAES, Enables WinZIP AES encryption
 * MZ_SIGNING, Enables zip signing support
 * MZ_ICONV, Enables iconv string encoding conversion library

Not sure that's intended behaviour, even though it happens to be convenient for me at the moment.

[carlocab]

Actually, maybe I just misunderstand this test:

-- Performing Test Iconv_IS_BUILT_IN
-- Performing Test Iconv_IS_BUILT_IN - Failed
-- Using Iconv

Anyway, thanks for having a look!