Solvedndk [BUG] CMake's find_library returns incorrect libdl

Description

In CMake projects, find_library picks up the wrong libdl.a: It returns ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/arm-linux-androideabi/libdl.a instead of ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/arm-linux-androideabi/24/libdl.so. The former is just a stub implementation (dlopen() always returns NULL), so it seems preferable to use the latter.

Notably, this breaks SDL2 for me, since it relies on dlopen to do anything interesting on Android.

Example CMakeLists.txt:

cmake_minimum_required(VERSION 3.13)
project(dlopen_test)
find_library(DLPATH dl)

# cmake -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake -DANDROID_PLATFORM_LEVEL=24 -DANDROID_PLATFORM=android-24 && cat CMakeCache.txt  | grep DLPATH

I found that reverting the change to CMAKE_SYSTEM_LIBRARY_PATH in 12d79d64f29f5f392183a1d1f763dbdfcebe7919 (i.e. prefixing that variable with the sysroot path again) resolves the issue for me, but I'm not sure this is a proper fix.

Environment Details

  • NDK Version: 19.1.5304403 (also tried copying android.toolchain.cmake from git over my NDK)
  • Build system: cmake
  • Host OS: Linux, openSUSE Tumbleweed
  • ABI: Any (e.g. arm64-v8a)
  • NDK API level: Any (e.g. 24)
26 Answers

✔️Accepted Answer

@enh Hah, interesting. Thanks for shedding some light on that :)

I can now confirm that adding NAMES libdl.so to the find_library call works. I'll check with the SDL developers to see if this change can be upstreamed.

This works on my end - feel free to close this issue at your discretion. From what you're saying it seems this is a necessary evil that we can't really do anything about in the NDK.

Thanks for your help!

Related Issues:

25
ndk React Native apps fail to build since NDK update to r17 (due to missing mipsel-linux-android-4.9 toolchain files)
The problem is that a given gradle plugin does not support every version of the NDK and the NDK is b...
4
ndk [BUG] CMake's find_library returns incorrect libdl
@enh Hah interesting Thanks for shedding some light on that :) I can now confirm that adding NAMES l...