text relocations despite -fPIC?

Question

I'm trying to recompile a decently-sized software stack (doubango) for ARM. After two weeks, I thought i finally got it done because the libraries that had text-relocations were no longer having them for armeabi, armv5te, armv7-a. However, armv7-a-neon still have them...

I know that linking against static libraries or shared libraries that contain text relocations will introduce them in my library as well, and to fight that one should use -fPIC in his CFLAGS while recompiling everything to build position independent code. All that's done, I built FFMPEG without text-relocations as well...

What I don't understand is this: If i'm using the same set of source-files for all archs, and manually checking by hand whether the .a files have text-relocations, why does only a single text-relocation appear for ARMv7 NEON ?

I'm checking using readelf like so readelf -a <libame.a> | grep TEXTREL for both .a and .so libs.

devshark@ubuntu:~/SCRATCH/doubango_env/doubango/android-projects/output/gpl/armv7-a-neon/lib$ readelf -a libtinyWRAP.so | grep TEXTREL 
   0x00000016 (TEXTREL)                    0x0
   0x0000001e (FLAGS)                      SYMBOLIC TEXTREL BIND_NOW

How do I find the culprit that's introducing the text relocations in my armv7neon .so library?

I'm using NDK r12b. Here's a pastebin of the whole build output: OK, no pastie or pastebin since they won't allow 2.1mb of text.

Great. So, any ideas why text relocations are appearing only for NEON?

The question could be simialr to this one, except that i don't have relocations for x86 either. Why is NDK generating shared library for x86 with text relocation even after setting -fPIC flag?

Answer 1

If everything is being built with -fPIC, the remaining text relocations are generally in any hand written assembly.

It looks like ffmpeg is known to have some text relocation issues with its assembler code:

• Report on the Android bug tracker (closed, not an Android bug): https://code.google.com/p/android/issues/detail?id=191235
• ffmpeg bug: https://trac.ffmpeg.org/ticket/4928
• Another question about this here that claims there is a fix: https://stackoverflow.com/a/34697703/632035