Can't add linker options no matter what

Usage
1

Hey folks, not sure what I’m doing wrong here. I’m attempting to build a CMake project, github .com/duckdb/duckdb_spatial for Android and am failing to set linker options for a dependency.

The project uses a Makefile to kick off its build. So in order to do the simplest thing that could possibly work, I add a simple build target pointing to the hard-coded NDK rules path on my system:

android_release:
	mkdir -p build/release/android && \
	cmake $(GENERATOR) $(BUILD_FLAGS)  $(CLIENT_FLAGS)  -DCMAKE_BUILD_TYPE=Release -S ./duckdb/ -DCMAKE_TOOLCHAIN_FILE=/home/nolan/android/android-ndk-r27c/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -B build/release/android && \
	cmake --build build/release/android --config Release

Running that gives me this:

[ 40%] Linking C shared library libz.so                                                                            
ld.lld: error: version script assignment of 'local' to symbol 'gz_intmax' failed: symbol not defined               
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The solution (github .com/llvm/llvm-project/issues/75056, edited because I exceeded the number of links I can post) seems to involve adding -Wl,--undefined-version to my linker flags and nothing I do seems to achieve that. Things I’ve tried:

  • LDFLAGS="-Wl,--undefined-version" make android_release
  • Adding -DLDFLAGS=-Wl,--undefined-version or -DCMAKE_LDFLAGS=-Wl,--undefined-version to the new android_release target defined above
  • Adding the above -D flags here
  • Adding add_link_options(-Wl,--undefined-version) here

Nothing makes a difference and this compilation error persists. zlib is added as an external project vendored in the source tree, and appears to be built via cmake as well. How do I add a linker option that isn’t another library to the zlib project? Bonus points if I can scope the option specifically to Android builds.

Thanks.

2

Wanted to bump this since I’m periodically returning to this and smashing my head against it without a lot of success. My latest attempt:

# ZLIB
ExternalProject_Add(
    ZLIB
    URL ${CMAKE_CURRENT_SOURCE_DIR}/vendor/zlib1213.zip
    CONFIGURE_HANDLED_BY_BUILD TRUE
    CMAKE_ARGS
    -DCMAKE_INSTALL_PREFIX:PATH=${LOCAL_INSTALL_DIR}
    -DCMAKE_PREFIX_PATH=${LOCAL_INSTALL_DIR}
    -DCMAKE_MODULE_PATH=${LOCAL_INSTALL_DIR}/lib/cmake
    -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
    -DCMAKE_OSX_ARCHITECTURES=${CMAKE_OSX_ARCHITECTURES_PACKED}
    -DCMAKE_POSITION_INDEPENDENT_CODE=ON
    -DBUILD_SHARED_LIBS=OFF
    ${CMAKE_FLAGS_POINTER_SIZE}
    # vcpkg options
    -DVCPKG_MANIFEST_DIR='${VCPKG_MANIFEST_DIR}'
    -DVCPKG_INSTALLED_DIR='${VCPKG_INSTALLED_DIR}'
    -DCMAKE_TOOLCHAIN_FILE='${CMAKE_TOOLCHAIN_FILE}'
    -DVCPKG_TARGET_TRIPLET='${VCPKG_TARGET_TRIPLET}'
)

# I added this:
target_link_options(zlib, -Wl,--undefined-version)

This gives:

-- Detecting CXX compile features - done                                                                           
CMake Error at CMakeLists.txt:60 (target_link_options):                                                            
  Cannot specify link options for target "zlib," which is not built by this                                        
  project.

Duh it isn’t built by this project, but it seems like a build system aught to allow me to add target-specific link options to a subproject if I happen to know that a given toolchain requires them. I don’t know why this is so difficult and I’ve been pouring through docs/SO posts/GitHub issues without a lot of success. Interestingly, this post now shows up in my Google results for this problem.

Thanks so much for any help. Apologies for the spammy-looking attempts at links in the first post.

3

I don’t have an answer, but I can tell you right away, that the ExternalProject just kicks off a separate build. That means you will not have “zlib” available to you right away, and at the moment you’ll have it (for example found by find_package), it will already be built, thus not accepting any modifications to the build process.

Note that FetchContent does not have this limitation.