Skip to content

Common build problems

Nathan Moinvaziri edited this page Jun 16, 2022 · 10 revisions

This is a running list of common build problems that have been encountered with zlib-ng and how to resolve them.

Using zlib-ng with third-party projects in CMake

First add zlib-ng using add_subdirectory then set the ZLIB_INCLUDE_DIR and ZLIB_LIBRARY variables to help find_package locate the correct paths to zlib-ng.

add_subdirectory(zlib-ng zlib-ng EXCLUDE_FROM_ALL)

# Set ZLIB variables for find_package used by other projects
set(ZLIB_INCLUDE_DIR ${CMAKE_BINARY_DIR}/zlib-ng CACHE STRING "Path to zlib include directory")
set(ZLIB_LIBRARY ZLIB::ZLIB CACHE STRING "Path to zlib library")

# Setup zlib alias project so FindZLIB doesn't recreate it
add_library(ZLIB::ZLIB ALIAS zlib)

# Add third-party CMake project
add_subdirectory(libpng)

Unknown Type Name Z_EXTERN

The following problem may occur when trying to integrate with zlib-ng and is due to zconf.h not being found.

zlib.h:218:1: error: unknown type name 'Z_EXTERN'
Z_EXTERN const char * Z_EXPORT zlibVersion(void);
^
zlib.h:218:31: error: expected ';' after top level
      declarator
Z_EXTERN const char * Z_EXPORT zlibVersion(void);
                              ^

Both zlib and zlib-ng produce a configuration file called zconf.h in the binary directory when building and third-party applications must add this binary directory as an include directory so that the configuration file can be found when compiling.

If integrating zlib-ng with CMake using add_subdirectory, the second parameter binary_dir can be explicitly stated and then added as an include directory:

add_subdirectory(${ZLIB_SOURCE_DIR} ${ZLIB_BINARY_DIR})
include_directories($(ZLIB_BINARY_DIR})

Relocation Error in compress2

The following problem may occur when building shared libraries using CMake due to zlib-ng's use of the -fno-semantic-interposition compiler flag.

/usr/bin/ld: compress.c.o: relocation R_X86_64_PC32 against symbol `compress2' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

The suggested workaround is to another linker such as lld or gold.

export LDSHARED=lld

-fno-semantic-interposition is useful to prevent some of the potential symbol collision problems. If zlib-ng in compat mode is loaded into a process, either statically or shared, it could collide with stock-zlib that is loaded by another library, for example openssl. Using -fno-semantic-interposition lets the compiler optimize zlib-ng code better, because it can assume that when we call a function that we also export, we will always run a zlib-ng function and not some random other one with the same definition.

For another description of the problem see https://note.f5.pm/go-53614.html.