Android dlopen failed cannot locate symbol

AS2.3 new issue: dlopen failed: cannot locate symbol «__emutls_get_address» #329

Comments

MeteC commented Mar 16, 2017

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

Further than that, I’m in the dark.

I’ve tried, with no success:

• building as both add_library(gr4coms SHARED $) and add_library(gr4coms STATIC $)
• 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

The text was updated successfully, but these errors were encountered:

DanAlbert commented Mar 16, 2017

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.

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

MeteC commented Mar 20, 2017

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 commented Mar 22, 2017

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 commented Mar 24, 2017

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 commented Mar 27, 2017

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:

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

DanAlbert commented Mar 28, 2017

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 commented Mar 28, 2017

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:

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

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

DanAlbert commented Apr 18, 2017

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.

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 commented Apr 21, 2017

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 commented Sep 8, 2017

possibly related to issue #498 ?

DanAlbert commented Oct 3, 2017

Is this still an issue?

MeteC commented Oct 3, 2017

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

DanAlbert commented Oct 3, 2017

ravarora commented Aug 14, 2018

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 commented Sep 6, 2018

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 commented Aug 15, 2019

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.

Источник

dlopen failed: cannot locate symbol (java.lang.UnsatisfiedLinkError) #1185

Comments

Gibson85 commented Feb 8, 2020 •

Hi, have problems linking multiple shared libs (with circular dependencies) against my native android app/lib.

My CMake looks like this:

I also checked the shared lib. The «missing» symbol is still existing. If I open the shared lib per dlopen on Linux.

. I don’t get a error message. So why android can’t link these libs? Any ideas what I could check to find the reason?

The text was updated successfully, but these errors were encountered:

alexcohn commented Feb 9, 2020 •

Try to load the library that you doubt about in Android directly from Java, i.e.

The diagnostic may help you understand what went wrong.

Gibson85 commented Feb 9, 2020

Thanks for your quick response. I did so using the «hello-libs» NDK example, but it gives me the same error:

Anything else I could try?

Gibson85 commented Feb 9, 2020

Is there a way I could extract the libs packed into the apk file to see if the symbol was maybe stripped away later? There is an apk inspector but there seems not to be an export option. Or maybe it could be a name mangling issue? The symbol that was not found is a class member function. I checked the existing of the function symbol with (readelf -Ws libMyLibB.so).

Gibson85 commented Feb 9, 2020 •

Ah maybe I found the reason.
The libMyLibB.so in the «build/intermediates/stripped_native_libs» directory contains the function symbol but it is declared as «NOTYPE» .

. while the function symbol of the original lib looks like this:

Could this be an error caused by the stripping?

alexcohn commented Feb 10, 2020

The libraries can be extracted from an APK with simple unzip .

But I am afraid I don’t understand what you found about libMyLibB.so. Please try to load this library alone, because now your findings may be obscured by the other libraries involved.

And I hope the missing symbol has some meaningful characters where you show dots.

Gibson85 commented Feb 10, 2020 •

It’s getting crazier and crazier.
Today I compiled everything again and suddently without having changed anything all linking problems are gone. I also unzipped the generated apk file’s libs and the missing symbol was existing (now). After that I run my app once, but sadly still the log message in my «ANativeActivity_onCreate» function did not appear in logcat (I am not using android_native_app_glue). Then I did a second run and suddently the message appeared! But after the third and forth run not again.

So my guess was that at the end the code was executed well all the time, but maybe the log message was not logged properly by Android Studio. After having run my app for about 100 times now I can say that the log messages appeared for only about 3 times. But you can imagine that this is completely unacceptable. Even break points are not getting hit then at all. There’s something completely strange in that very early program startup phase. All my app is doing for now is printing the following log message:

One other thing I recognized was that when having copied my latest compiled libs to the android app directory even after a build or «Refresh linked C++ Projects» the apk was not updated at all. So at least now I now I always have to do a complete rebuild.

So what I would like to know:

1.) Is there a way to ensure that the log message gets logged? Is there maybe a flush function for that purpose? I guess «__android_log_print» will buffer the messages on first step.

2.) If I set the «android:hasCode=false» property in my manifest file I see a.

. message in my logcat with an obvious empty path. What does that mean?

3.) Sometimes I see the following log messages in my locat also:

But it’s luck if it is logged or not. Maybe there are timing issues in this early program phase?

Gibson85 commented Feb 10, 2020

Here’s a full thread dump after startup. Can you see something unusual here?

enh-google commented Feb 11, 2020

Regarding breakpoints at this very early stage – they aren’t reliable. We put a loop with sleep that polls some global variable before the first breakpoint that we set. Then we start the app, suspend it when it finally gets connected to debugger, change the global variable to false , and resume the execution.

i asked the Studio folks about this, and it’s news to them. (they also couldn’t reproduce with a trivial example.) if you have repro steps, file a bug with them (https://developer.android.com/studio/report-bugs). if you let me know the bug id i’ll make sure the right folks get to see it.

alexcohn commented Feb 11, 2020

@enh-google I don’t have a working example of unreliable breakpoints at hand, I am no longer working for that company. And quite possibly, this happened only on some devices, and not with the latest versions of AS and SDK.

My comment was not a form of bug report. My point was that if AS doesn’t show something in logcat window or stop at some breakpoint, it does not necessarily mean that this code is not executed.

alexcohn commented Feb 11, 2020

Here’s a full thread dump after startup. Can you see something unusual here?

why should there be anything unusual?

Gibson85 commented Feb 11, 2020 •

@enh-google
I am fighting with these annoying problems since weeks now.
So do me a favour. Take your android studio folks and kick them into their ass from me.
I can’t believe what a saw now.

I thought the debugger would be broken completely, because the lines (e.g. at NativeActivity.java) I had put the breakpoints on, had been greyed out because there would be no executable code. «Luckily» I only found these greyed out lines. Now I did a new try and there are really lines you can put a «working» breakpoint on. By the way there are IDEs that will move the breakpoint to the next line that can be executed. But thats not the problem at all. I placed now three breakpoints that not had been greyed out and started debugging. All these three breakpoints have a checkmark also. But the first breakpoint.

NativeActivity.java line 160:

. never gets hit at all.
Ok, but there are two other chances left. So lets hope the best.
The second breakpoint at line 167.

. really gets hit.
Originally I was interested in line 170 and the return value, but as said before the breakpoint was greyed out. So finally the third breakpoint at line 176 was hit also and showed that the «mNativeHandle» was zero. Ok, that was unexpected to me. Then on next line 177 the «UnsatisfiedLinkError» exception was thrown claiming it couldn’t find my app’s shared lib. Fun part. This exception never was logged in logcat and even crazier although an exception was thrown the next line 180

was executed nevertheless.

And that’s not all.

I have to control myself very much now.
In this fuc. logcat window now all these log messages I wanted to see since weeks appeared. Most probably because your shitty Android is completely broken with maybe heavy multithreading or other timing problems. If I step through the code with the debugger all these messages appear now but not by running it!

BUT THATS STILL NOT ALL!

Before I started these debugger sessions I commented out this fuc. «ANativeActivity_onCreate» function and even veryfied by readelf that there is not a single «ANativeActivity_onCreate» symbol at any lib I was linking to. I also verified that I had activated the linker flags that no missing symbols are allowed. In addition I did a project cleanup, refreshed linked C++ projects and did a complete rebuild not only once I did it twice.

BUT STILL I WAS GETTING THESE LOG MESSAGES IN THE ANDROID STUDIOS LOCAT WINDOW FROM A FUNCTION NOT BEING EXISTEND ANYMORE.

Finally I removed all android build files manually and believe it or not now I got what I would have expected before:

But again. The above log message only appears when stepping through the code with the debugger. If you «Run» the code there is nothing!

THERE IS NOTHING!

I hope this is trivial enough for you and your android folks to find out the bugs.
And I hope this will be fixed soon. And by the way. If that behavior gets proven by you folks,
I think the least you could do to me is paying a monthly salary as compensation :D.

I wish I would not have get confused by the greyed out breakpoints respectively by breakpoints not getting hit at all. That could have saved me a lot of time because I was completely blind on «debugging».

To be honest. Please fix these annoying problems. Please!

Источник