So here's what seems to be happening:
mariadbclient is configured using CMake. Specifically, it uses CMake's FindZLIB.cmake to find zlib.
FindZLIB.cmake uses CMake's find_library function to find libz.dylib.
find_library searches, among other places, "<prefix>/lib for each <prefix>/bin in PATH".
If Miniconda is installed and set up, Miniconda's bin directory is on the PATH, so CMake will search in Miniconda's lib directory.
Miniconda's lib directory contains libz.1.dylib version 1.2.8. CMake will find this and link libmariadbclient.dylib against it.
daf_persistence tries to link against libmariadbclient.dylib. Even if Miniconda is set up at the time, it does not add it's lib directory to the linker path. Instead, we figure out the path to link against libpython by asking the Python interpreter what we should use, and it points us to miniconda/lib/python2.7/config. This does not contain libz.dylib.
Therefore, we fall back to trying to link against the system /usr/lib/libz.dylib. This is an older version (1.2.5 vs the Miniconda supplied 1.2.8), and linking fails. Exactly why it reports such an unhelpful message when it fails isn't clear to me, but it does. You can even ask ld to show you the libraries it's loading using the -t flag: watch it load /usr/lib/libz.dylib then follow that up by telling you that libz.dylib is not found.
The workaround would seem to be to stop mariadbclient linking against Miniconda's zlib. However, that's easier said than done. Convincing CMake to not consider "each <prefix>/bin in PATH" seems to involve editing the FindZLIB.cmake that's distributed as part of CMake itself and adding NO_SYSTEM_ENVIRONMENT_PATH arguments to various function calls. That seems impractical.
An alternative is to pass CMAKE_SYSTEM_IGNORE_PATH=<PATH_TO_MINICONDA>/lib to the cmake executable on the command line. A simple-minded approach to this is here. One might worry about what happens when the python executable isn't provided by Miniconda; I guess some extra checks could insure against that.
Another option is to simply force CMake to find the system zlib on OSX by adding -DZLIB_ROOT=/usr to the CMake invocation. That's here. In this case, you might worry that the user could have some other zlib that they really want to be used instead – seems unlikely, though.
For what it's worth, neither of the above options seem elegant to me, but they both resolve the daf_persistence build issue on my system. Anybody got a better idea?