libavcodec.so: has text relocations

Question

I\'m testing Android 6.0 on a Nexus 5 and i\'m using Metaio (I know that the service is going to end on the 15th of december but for that date we\'ll move to another AR plat

Answer 1

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.

Answer 2

After a long time struggling and trying to compile FFmpeg in different ways, I found the solution. Make sure to compile FFmpeg with the --disable-asm flag. This will make sure that FFmpeg wouldn't have text relocations and won't crash when compiling against Android M (SDK 23)

To make sure it worked, you can use readelf as mentioned above.

Cheers

Answer 3

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

readelf -a path/to/yourlib.so | grep TEXTREL

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

0x00000016 (TEXTREL)                    0x0

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

ndk-build -B -j 8

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

Answer 4

OK I've got this working here even with targetSDK 23 set.

For me and my branch the five files that required patching were

libavcodec\arm\fft_fixed_neon.S  
libavcodec\arm\fft_neon.S  
libavcodec\arm\fft_vfp.S   
libavcodec\arm\mlpdsp_armv5te.S  
libutil\arm\asm.S  

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.

Answer 5

I received feedback from metaio's SDK team. They say that this issue cannot be easily solved by metaio, as it is related to the FFMpeg library. We would have to hope that an update of FFMpeg would fix the issue. I assume that we have to wait for such an update and to exchange the library files in the app.

I have not yet looked for a FFMpeg developer contact forum to make enquiries or to notify a bug. Do you know one by accident?

Best regrads, christin

Answer 6

Today, I got the same error messages when testing my app with Android 6.0 on a Nexus 6 (Motorola). I solved my issue by checking the targetSDKVersion in the manifest file. Using "22" and not "23" as targetSDKVersion solved it. (See below)

<uses-sdk
        android:minSdkVersion="15"
        android:targetSdkVersion="22" />

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

compileSdkVersion 22
    buildToolsVersion '22.0.1'

    defaultConfig {
        minSdkVersion 15
        targetSdkVersion 22
    }

Hope this will help you. However, this is just a short term workaround for now, I hope that we will get some feedback from metaio though.

Regards, christin