I am trying to recompile stacks of decent size software (doubango) for ARM. Two weeks later, I thought it finally happened, because libraries that had text permutations were no longer for them armeabi , armv5te , armv7-a . However, armv7-a-neon still have them ...
I know that linking to static libraries or shared libraries that contain text movement will also present them in my library, and to combat this, use -fPIC in your CFLAGS, recompiling everything to create position-independent code. All that is done, I built FFMPEG without text moves ...
I don’t understand what it is: If I use the same set of source files for all arches and manually check if the .a files have text swap files, why does a single text move appear for ARMv7 NEON
I test the use of readelf as follows readelf -a <libame.a> | grep TEXTREL readelf -a <libame.a> | grep TEXTREL for .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 to find the culprit who introduces text movement in my armv7neon .so library?
I am using NDK r12b. It uses the pastebin of the entire assembly: well, there is no paste or pastebin, since they will not allow 2.1mb of text.
Great. So, any ideas why text transitions appear only for NEON?
The question may be similar to this, except that I don't have permutations for x86. Why does the NDK create a shared library for x86 with text movement even after setting the -fpIC flag?