AS2.3 new issue: dlopen failed: cannot locate symbol "__emutls_get_address"

[MeteC]

Description

Since upgrading Android Studio to 2.3 (on Mac), my external cpp library (a proprietary TCP library) has started failing runtime loading with the error:

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__emutls_get_address" referenced by "/data/data/com.my.app.packagename/app_lib/libgr4coms.so"...

__emutls_get_address is a symbol that's part of TLS, it seems. (http://stackoverflow.com/questions/7885246/what-is-the-emutls-get-address-symbol)

Further than that, I'm in the dark.

I've tried, with no success:

• building as both add_library(gr4coms SHARED ${my_SRCS}) and add_library(gr4coms STATIC ${my_SRCS})
• building with gnu++11 as well as clang
• incuding ssl in target_link_libraries( ... ) - failed to link, cannot find -lssl

Environment Details

• NDK Version: 14.0.3770861
• Build sytem: CMake
• Host OS: Mac OSX 10.11.6
• Compiler: CMake default clang
• Android test device version 6.0.1

[DanAlbert]

I don't think I'm going to be able to figure out anything definitive without a test case.

It looks like libgr4coms was improperly built. __emutls_get_address should be baked into the library when it is built, but that appears to not have happened. I'm guessing the error here was by cmake rather than user error. I'll try to come up with a test case, but if you have a minimized case you could provide that would certainly save time.

NDK Version: 14.0.3770861

The other question here is whether this works if you downgrade to NDK r13. I don't think anything we've changed in cmake should have caused something like this...

incuding ssl in target_link_libraries( ... ) - failed to link, cannot find -lssl

Not that TLS ;)

[MeteC]

Thanks Dan. Sorry to say I don't really have a minimised case to provide.. it's part of a large (corporate) codebase, rather than a personal project of mine, so I don't really have the right to provide any of that code to the public for any purpose ;-)

I'll investigate downgrading the NDK to see what happens, I'll report back on my success there..

[MeteC]

Hi again,

Downgraded NDK from 14 to r13b - and the problem is gone.. So could it be a bug in NDK 14? Or a compatibility issue in my code maybe?

[DanAlbert]

Sorry for the slow response.

My best guess right now is that this is something like #289

Are you using the NDK's cmake toolchain, or the Android support that's built in to cmake 3.7+? It looks like there might be some bugs in the cmake 3.7 Android support that's causing libgcc things to not be linked properly. If that's the case, I'm going to dup this bug into the other. If not, I'll need to come up with another theory...

[MeteC]

Thanks Dan. I'm sorry I'm not 100% sure how to answer that.. I guess it's the NDK's cmake toolchain as I'm using Android Studio to do all the dirty work, would that be right? I'll attach some info here in the hope that it answers the question.

My gradle file contains:

defaultConfig {
    minSdkVersion 16
    targetSdkVersion 20
    versionCode 1
    versionName "1.0"

    // NDK settings
    ndk {
        abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a'
    }
    externalNativeBuild {
        cmake {
            arguments '-DANDROID_STL=c++_shared', '-DANDROID_TOOLCHAIN=gcc', '-DANDROID_PLATFORM=android-16'
        }
    }
}
externalNativeBuild {
    cmake {
        path 'src/main/cpp/CMakeLists.txt'
    }
} 

While the CMake file is pretty uncomplicated, but begins with cmake_minimum_required(VERSION 3.4.1)

[DanAlbert]

Yeah, if you're using Android Studio it will be our toolchain rather than the upstream one. That turns out to have not been the issue in the other bug, but actually just a generic bug in cmake, it seems. See the other bug for the gory details, but this was the workaround:

One thing you might try: add -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libunwind.a to your ldflags. That will ensure that both unwinders end up hidden in anything they get included in so you don't have the problem above for at least those libraries. Note: the -Wl,--exclude-libs,libunwind.a is actually only needed on arm32.

Let me know if that fixes your problem. If so, I'll dup this into the other.

[MeteC]

So I gave it a shot, but no luck... I tried two different ways of adding it in CMakeLists, one using target_link_libraries(gr4coms atomic log -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libunwind.a) and then again, just in case, I set both CMAKE_SHARED_LINKER_FLAGS and ANDROID_LINKER_FLAGS manually:

SET(NDK_WORKAROUND_LINK_FLAGS    "-Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libunwind.a")
SET( CMAKE_SHARED_LINKER_FLAGS  "${CMAKE_SHARED_LINKER_FLAGS} ${NDK_WORKAROUND_LINK_FLAGS}" )
SET( ANDROID_LINKER_FLAGS  "${ANDROID_LINKER_FLAGS} ${NDK_WORKAROUND_LINK_FLAGS}" )

Printing out all of my CMake variables includes the following maybe-helpful info:

-- The C compiler identification is GNU 4.9.0
-- The CXX compiler identification is GNU 4.9.0
-- CMAKE_BUILD_TOOL=/Users/mcakman/Library/Android/sdk/cmake/3.6.3155560/bin/ninja 
-- CMAKE_SHARED_LINKER_FLAGS=-Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -L/Users/mcakman/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/arm64-v8a -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -L/Users/mcakman/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/arm64-v8a -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now  -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libunwind.a
-- ANDROID_LINKER_FLAGS=-Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--fix-cortex-a8 -Wl,--exclude-libs,libunwind.a -L/Users/mcakman/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libunwind.a

I also noted that -Wl,--exclude-libs,libunwind.a was actually included in most linker flag settings already...

[DanAlbert]

Apologies for slow response, been on vacation.

Hmm. Did those flags get added for each library you built? Maybe there was a prebuilt library you're using? Possibly even libc++_shared.so is the problem...

$ readelf -sW $NDK/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++_shared.so | grep __emutls_get_address
  2128: 00084f00   316 FUNC    GLOBAL DEFAULT   11 __emutls_get_address

But even so, libc++_shared.so is being shipped with your app, so it should be found. Are you using a NativeActivity? Could you by any chance share the full link command for your library?

[MeteC]

There's only one library being built with the NDK, and no prebuilt libraries, apart from standard ones (target_link_libraries(gr4coms atomic log)). No NativeActivity used. The library built (gr4coms) is a TCP client/server library.. I'll see if I can ferret out the link command soon..

[enh]

possibly related to issue #498 ?

[DanAlbert]

Is this still an issue?

[MeteC]

Sorry should have mentioned this before - happily NDK version 15 has cleared up this issue 👍

[DanAlbert]

🎉

[ravarora]

Facing the exact same issue while building x86 builds .
with NDK 14b it works fine.
with NDK 17 and NDK 18 beta 1 it fails with the same error as defined in the initial problem

When i try using the flags "-Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libunwind.a" with NDK 18 beta 1

I get the following error
CMake Error at D:/MONugetCache/androidsdk.26.0.2/ndk-bundle/build/cmake/android.toolchain.cmake:265 (message):
gnustl_shared is no longer supported. Please switch to either c++_shared
or c++_static. See
https://developer.android.com/ndk/guides/cpp-support.html for more
information.
Call Stack (most recent call first):
D:/MONugetCache/androidsdk.26.0.2/cmake/3.6.4111459/share/cmake-3.6/Modules/CMakeDetermineSystem.cmake:98 (include)
CMakeLists.txt:2 (project)

[Acrobot]

For anybody else in the future, who might have the same problem — I have tracked down the issue to NDK r16b and NDK r17b not working with each other properly.

I had a library compiled with NDK r16b and it required __emutls_get_address symbol (which was normally provided by libc++_shared.so from NDK r16b), however when later compiling my application with NDK r17b, the libc++_shared.so provided by the newer NDK no longer had the symbol inside. I fixed it by compiling both with NDK r16b, however compiling both with NDK r17b could possibly work as well.

[luomomo]

For anybody else in the future, who might have the same problem — I have tracked down the issue to NDK r16b and NDK r17b not working with each other properly.

I had a library compiled with NDK r16b and it required __emutls_get_address symbol (which was normally provided by libc++_shared.so from NDK r16b), however when later compiling my application with NDK r17b, the libc++_shared.so provided by the newer NDK no longer had the symbol inside. I fixed it by compiling both with NDK r16b, however compiling both with NDK r17b could possibly work as well.

Hi,I meet this problem now .I use ndk 16b，but my partner use ndk17，code works for him but not for me. I read your code several time but still can not know how you solve this.

[DanAlbert]

Update your NDK.