Android NDK UnsatisfiedLinkError: “dlopen failed: empty/missing DT_HASH”

Question

I am tracking down crashes with our Android application (which uses the NDK to load a C++ library) using a crash reporting service. A small number of users are experiencing the

Answer 1

I have faced this problem while using Android Cmake and I have set -DANDROID_PLATFORM=23 As per changelog The GNU hash style becomes available from API 23 and because of ANDROID_PLATFORM was set to 23 the flag --hash-style=gnu was set automatically.

I have fixed this just by lowering -DANDROID_PLATFORM=21and then the flag was set to the flag --hash-style=both

Answer 2

To see if it is hash-style problem you can run readelf -d cpplibrary.so and look for GNU_HASH section. If there is one - --hash-style=sysv should solve the problem.

Answer 3

Although out of this question, I met this problem in Android Studio import third-party so file. Finally I found this is because Gradle automatically stripped the product 'so' file, so disabling this option it works.

android {
	........
    packagingOptions{
        doNotStrip "*/armeabi-v7a/*.so"
    }
   .......
}

Answer 4

The library you are trying to load was most likely built with -Wl,--hash-style=gnu. This was not supported on Android until recently (afaik this isn't even in L). You need to build your libraries with -Wl,--hash-style=sysv.

How did you build cpplibrary.so? If you didn't do anything to manually switch to the gnu hash style, it could be a bug in the NDK.

Answer 5

This might be due to different arhitectures of target devices. Are you able to collect device vendor/model information from crash reports ? Not sure, but I guess you need to compile you native library across multiple archs (armeabi, armeabi-v7, neon) to overcome such incompabilities.

Answer 6

If you're a third party building .so libraries for others to use, setting -Wl,--hash-style=both seems like the best idea. That gets you the faster loading of the Gnu-style hash and the backwards compatibility of the SysV hash.