Android NDK UnsatisfiedLinkError: “dlopen failed:

问题:

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 following crash:

java.lang.UnsatisfiedLinkError: dlopen failed: empty/missing DT_HASH in "cpplibrary.so" (built with --hash-style=gnu?)
   at java.lang.Runtime.loadLibrary(Runtime.java:365)
   at java.lang.System.loadLibrary(System.java:526)

The couple of mentions of this error I can find on the internet (for example this Google Groups post) discuss problems with building the libs, which cause this error to occur every time the app is run. There is little information on why this might happen sporadically. This post is the closest I can find.

Based on the crash traces, it looks like any particular user will experience this constantly for stretches; I am not sure if these users are ever able to load the lib correctly. Does anyone have ideas on what might cause this to happen only sometimes? Can I do the NDK build differently to try and stop it?

Thanks!

Edit: This post mentions two ways to get such errors conditionally; I will be looking in to them.

Edit2: Build files: Android.mk (excerpt):

include $(CLEAR_VARS)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)
LOCAL_C_INCLUDES := <Source Path>...
LOCAL_CFLAGS := -DANDROID -Wall
LOCAL_CPPFLAGS := -DENABLE_SDK_DEBUGGING=1 -DENABLE_SDK_LOGGING=1
LOCAL_MODULE := cpplibrary
LOCAL_SRC_FILES := <Source Files> / ...

LOCAL_LDLIBS    := -llog -landroid
LOCAL_STATIC_LIBRARIES := cpplibrary
include $(BUILD_SHARED_LIBRARY)

Application.mk:

APP_STL := stlport_static
APP_CFLAGS += -std=c++11

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

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.