Reputation: 6416
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?
Upvotes: 5
Views: 4968
Reputation: 10509
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:
Upvotes: 7