CODEWITHSUNDEEP
androidc++android-ndklinkerjava-native-interface
Tbadams
Tbadams

Reputation: 469

Android NDK UnsatisfiedLinkError: "dlopen failed: empty/missing DT_HASH"

I am tracking down crashes with our Android application (which uses the NDK to load a custom 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

Upvotes: 17

Views: 16743

Answers (10)

mobileappz
mobileappz

Reputation: 89

If you are facing this problem with an Android API 35 emulator or device, and you are using Android NDK r27 and higher try this:

In your build.gradle file, set the argument -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
      }
    }
  }
}

Upvotes: 1

Jesse Wilson
Jesse Wilson

Reputation: 40585

My team observed a similar crash but with an unrelated cause. Our crash looked like this:

java.lang.UnsatisfiedLinkError: dlopen failed: 
  empty/missing DT_HASH/DT_GNU_HASH in
  "/data/app/~~ZxUFcGuDQcv9ij_KMRXCVQ==/app.cash.zipline.test-K-VxaF1awxuos15EVjM0lQ==/lib/arm64/libquickjs.so"
  (new hash type from the future?)

And the fix was to follow the Android guide to Support 16KB pages.

Upvotes: 3

John Dallman
John Dallman

Reputation: 694

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.

If you're only supporting Android 8 and later, there's no need to support the SysV hash.

Upvotes: 5

Fedorov7890
Fedorov7890

Reputation: 1245

In case somebody is building a Rust library for Flutter using this project template, changing corresponding line in the makefile to ANDROID_ARMV7_LINKER=$(ANDROID_NDK_HOME)/toolchains/llvm/prebuilt/$(OS_NAME)-x86_64/bin/armv7a-linux-androideabi22-clang will help.

Upvotes: 0

Roman Nazarevych
Roman Nazarevych

Reputation: 7703

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

Upvotes: 3

Jian Guo
Jian Guo

Reputation: 740

--hash-style=both should work. Check https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#gnu-hashes-availible-in-api-level-23 as refs.

Upvotes: 1

jdir.s
jdir.s

Reputation: 131

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"
    }
   .......
}

Upvotes: 1

dimitry
dimitry

Reputation: 61

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.

Upvotes: 0

Dan Albert
Dan Albert

Reputation: 10499

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.

Upvotes: 3

Efe Kahraman
Efe Kahraman

Reputation: 1438

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.

Upvotes: 0

Related Questions