Android: dlopen fail due to has text relocations issue


For some reason, I found out some Apps I programmed several years ago, rebuilt them and put on my MI NOTE (Android 6.0) to run some tests.

Here is my cross compile environment:

  • NDK: former downloaded, r7c + r8b
  • SDK: newly downloaded, 24.4.1

But when I tried to run the App on my phone, I got an error like this:

Solutions 1:

This issue could be solved by checking the targetSDKVersion in the manifest file.

Using “22” and not “23” as targetSDKVersion solved it. (See below)

I also checked the build.gradle files for compile version and targetSDKversion:

Solutions 2:

It was caused by the ffmpeg, and it could also be solved by patching the latest ffmpeg code

I took the latest from https://github.com/FFmpeg/FFmpeg

You will also need HAVE_SECTION_DATA_REL_RO declared somewhere in your build for the macro in asm.S to use the dynamic relocations option.

Further informations:

Previous versions of Android would warn if asked to load a shared library with text relocations:

“libfoo.so has text relocations. This is wasting memory and prevents security hardening. Please fix.”.

Despite this, the OS will load the library anyway. Marshmallow rejects library if your app’s target SDK version is >= 23. System no longer logs this because it assumes that your app will log the dlopen(3) failure itself, and include the text from dlerror(3) which does explain the problem. Unfortunately, lots of apps seem to catch and hide the UnsatisfiedLinkError throw by System.loadLibrary in this case, often leaving no clue that the library failed to load until you try to invoke one of your native methods and the VM complains that it’s not present.

You can use the command-line scanelf tool to check for text relocations. You can find advice on the subject on the internet; for example https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide is a useful guide.

And you can check if your shared lbirary has text relocations by doing this:

If it has text relocations, it will show you something like this:

If this is the case, you may recompile your shared library with the latest NDK version available:

And if you check it again, the grep command will return nothing.

Leave a comment

Your email address will not be published. Required fields are marked *