42

My Android application (using native library) print this warning on Android 4.4 :

linker mylib.so has text relocations. This is wasting memory and is a security risk. Please fix.

Have you got an idea of what it is and how to fix it ? Thanks,

Raptor
  • 53,206
  • 45
  • 230
  • 366
Jerome
  • 1,153
  • 1
  • 17
  • 28

4 Answers4

26

This would appear to be a result of two ndk-gcc bugs mentioned at https://code.google.com/p/android/issues/detail?id=23203

and stated there to have been fixed as of ndk-r8c.

It would appear that the check for libraries with the issue has been added only recently.

Note: please do not edit this post to hide the link URL. It is explicit because the destination is what makes it authoritative.

Further Note Changing NDK versions is only a fix when the warning is due to the code of your application. It will have no effect if the warning is instead on a system component such as libdvm - that can only be fixed by a system update.

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
  • 3
    Having same error while installink apk with adb. Using ndk-r9d. – Olcay Ertaş May 19 '14 at 01:55
  • 3
    You said "bug". Can be ignored? Or is it a *real* issue? Thanks. – dentex Sep 21 '15 at 14:59
  • 1
    @Chris Stratton I got the same warning and I'm using android-ndk-r10e. Isn't it possible that this bug points at someting wrong in the lib.so. For instance not releasing dynamic memory or something – VMMF Aug 19 '16 at 23:41
  • This answer is very old and is now incorrect for any modern version of the NDK. See my answer below for the more likely solution. – Reuben Tanner Apr 06 '17 at 15:10
  • @HypotheticalintheClavicle the whole point is that this is *caused* by using an old version of the NDK with unfortunate default behavior. Do note the explicit mention of Android 4.4 in the question. Your answer does not apply to the actual question asked, though it may be useful for related situations in *other* contexts. Also see the note cautioning against mistaking warnings on *system* libraries for those on the libraries actually *provided* in the apk. – Chris Stratton Apr 06 '17 at 15:30
4

You need to make the code in your library position independent...add -fpic or -fPIC to your LOCALC_FLAGS in your Android.mk and you also need to ensure that you're not linking against any static or shared libraries that contain text relocations themselves. If they do and you can re-compile them, use one of the flags mentioned above.

Reuben Tanner
  • 5,229
  • 3
  • 31
  • 46
  • I tried, in both dependency lib and the executable. They compiled fine but I have the same warning. Are you sure it's the right switch? – dentex Sep 21 '15 at 14:56
  • 1
    You have to ensure you're using the right switch for the arch type you're compiling for. Also, you can use `objdump` on your .a or .so to see if they have text relocations. _They themselves_ might link against libraries that have relocations as well. – Reuben Tanner Sep 21 '15 at 16:12
  • 1
    You should also trace `LOCALC_FLAGS` (or whatever that variable is named) through your build script to see if it is getting passed to the libraries in question. – Reuben Tanner Sep 21 '15 at 16:32
  • 1
    Thanks. One thing. As stated above, this should be a "bug". Can be ignored? Or is it a real issue? – dentex Sep 22 '15 at 13:05
  • 5
    It _can be_ a bug depending on the ndk version that compiled the .so and it looks like it fixed in 2012. If you are writing the library that you're compiling and it's generating this warning, you should fix it. As of Android Marshmallow, libraries with text relocations _will not_ produce a warning; they'll produce an error and your app will crash on launch. – Reuben Tanner Sep 23 '15 at 17:21
  • Thanks. I appreciate your help – dentex Sep 24 '15 at 06:44
  • 1
    After switching to the latest NDK, the `-fpic` flag seems to work: `readelf -a liblame.so | grep TEXT` returns nothing and also the new executable gives no warnings into the app. :) – dentex Sep 28 '15 at 08:52
  • Muy bien! Glad to help. – Reuben Tanner Sep 29 '15 at 14:56
  • @ Hypothetical inthe Clavicle Thank you, my app is crashing on M which was working on L smoothly, was wondering why. – Sagar Sakre Dec 14 '15 at 06:08
  • @SagarSakre, how can I know? You haven't told me anything. Please open a question that contains the necessary information like stack traces, device used, the repro steps etc.. – Reuben Tanner Dec 16 '15 at 18:51
  • 3
    @Clavicle. I fixed the issue already. In Android L text relocations were a warning but its a error in Android M. I fixed in the driver code after using the flags u mentioned – Sagar Sakre Dec 18 '15 at 09:32
4

In short, you need to compile your library with one of the -fpic or -fPIC flags, where PIC is an abbreviation for Position Independent Code.

The longer answer is that your yourlib.so has been compiled in a manner that does not conform to the Google Android standard for an ELF file, where this Dynamic Array Tag entry is unexpected. In the best case the library will still run, but it is still an error and future AOS version will probably not allow it to run.

DT_TEXTREL 0x16 (22)

To check whats in you library use something along the line of: 

# readelf --wide -S yourlib.so

There are 37 section headers, starting at offset 0x40:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        0000000000000000 002400 068f80 00  AX  0   0 16
  [ 2] .rodata           PROGBITS        0000000000000000 06b380 05ad00 00  WA  0   0 32
  ...
  [16] .rela.text        RELA            0000000000000000 26b8e8 023040 18     14   1  8
  ...
  [36] .rela.debug_frame RELA            0000000000000000 25a608 0112e0 18     14  27  8

Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Please see my extensive answer on the topic, for more DT entry details. For details how to write proper dynamic libraries this is a must-read.

Community
  • 1
  • 1
not2qubit
  • 14,531
  • 8
  • 95
  • 135
1

I got the same error with my application. The application was using a native daemon that used a native library which was not implementing all the functions in its header file. When I added the required implementations to the native library everything just worked.

I don't know if you have the exact same issue but it just probably means the your native side has some mismatch.

Ravit D
  • 907
  • 9
  • 27
  • What if you only use Java in the app and get the warning? – NoBugs Jan 16 '15 at 05:25
  • 3
    The resolution of your problem has nothing to do with the issue of this question. – Chris Stratton Sep 24 '15 at 21:39
  • The question asks about a fix for this warning. I had the same warning and a mismatch fix solved the issue. Maybe you don't have a native mismatch but it might help others that do have a mismatch and get that warning... – Ravit D Dec 29 '15 at 13:20