14

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
Tbadams
  • 424
  • 1
  • 5
  • 20
  • 2
    Did you ever find the cause of this? I'm having the same issue with a native library I'm building. Very few users see it, but some are getting a java.lang.UnsatisfiedLinkError caused by an `empty/missing DT_HASH in "libGLESv3.so" (built with --hash-style=gnu?)` – Cypress Frankenfeld Nov 30 '15 at 21:51

8 Answers8

5

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.

John Dallman
  • 590
  • 4
  • 18
  • No longer have access to the app issue was filed for, but I agree this seems to be the best possible advice. Quick Google suggests this problem spiked in 2015, then faded away, with anecdotal evidence for a bug in ReLinker. In any event, if you as a third party lib dev set it to 'both', I think you've done your due diligence. – Tbadams Dec 17 '18 at 21:57
3

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.

Dan Albert
  • 10,079
  • 2
  • 36
  • 79
  • Thanks for the suggestions. I am not currently setting the hash style anywhere. I can try explicitly setting it to sysv but because so few users encounter it I won't see results until our next app release. I will try it and see if anything different happens. – Tbadams Feb 24 '15 at 00:43
  • 1
    I have the same problem. As my problem is with a third party cpplibrary.so I cant simply build the library with `-Wl,--hash-style=sysv'`. Any suggestions? – Niels Nov 21 '18 at 08:52
  • 1
    Tell the author of the third party library that they're building it wrong. That's the only possible fix if you want to continue using that library. – Dan Albert Nov 27 '18 at 23:11
2

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

Roman Nazarevych
  • 7,513
  • 4
  • 62
  • 67
1

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"
    }
   .......
}
JJJ
  • 32,902
  • 20
  • 89
  • 102
jdir.s
  • 97
  • 8
1

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

Jian Guo
  • 708
  • 1
  • 9
  • 19
0

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.

Efe Kahraman
  • 1,438
  • 14
  • 21
  • Thanks, that is a good suggestion. That was one of my first suspicions for the problems, but all the devices with the crash are armeabi-v7, which we support. Also, the crashes are not 100% for every device; we have a Samsung S5 that works fine, but that is one of the crashing phones. – Tbadams Feb 23 '15 at 21:25
0

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.

dimitry
  • 51
  • 2
0

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.

Fedorov7890
  • 1,173
  • 13
  • 28