CMake finds the 32-bit libz by default on 64-bit Linux systems.

[ShimmerFairy]

I ran into this issue when building xlsxreader.plug.so, specifically looking like this:

[ 62%] Linking CXX shared module xlsxreader.plug.so
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libz.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status

The issue here is that /usr/lib/libz.so is the 32-bit version of the library. On many (if not most) systems, the 64-bit version is found in /usr/lib64/libz.so, and indeed manually setting ZLIB_LIBRARY_RELEASE to the correct path allowed the build to finish successfully.

[lethosor]

Could you share some more details about your distro? On Ubuntu, I have /usr/lib/i386-linux-gnu/libz.so and /usr/lib/x86_64-linux-gnu/libz.so, but no /usr/lib/libz.so, and I'm surprised that your zlib in /usr/lib is not the "native" (64-bit) build - I'd expect the 32-bit one to be in /usr/lib32 or somewhere else on a 64-bit OS. Are you running a 32-bit kernel with 64-bit userland support somehow?

Here is where we set the zlib search path, for reference. It only has a special case for 32-bit Linux; as far as I know (and on my end) it hasn't failed on 64-bit Linux before. Could you try adding message("ZLIB_ROOT = ${ZLIB_ROOT}") before and after the find_package call here and report what it prints out?

[lethosor]

@ShimmerFairy another question: what CMake version are you using? The FindZlib module we're using is built in to CMake, so it's possible that upgrading to a newer version would help.

[myk002]

Is this still an issue?

[myk002]

Closing for now. Please reopen if this is still an issue.