我试图为ARM重新编译一个体积适中的软件堆栈（doubango）。两周之后，我认为我终于完成了它，因为具有文本重定位的库不再具有armeabi，armv5te，armv7-a的库。但是，armv7-a-neon仍然拥有它们......
我知道链接静态库或包含文本重定位的共享库也会在我的库中引入它们，为了对抗它，应该在他的CFLAGS中使用-fPIC，同时重新编译所有内容以构建与位置无关的代码。完成所有这些工作后，我构建了没有文本重定位的FFMPEG ......
我不明白的是：如果我为所有的arch使用相同的源文件集，并手动手动检查.a文件是否有文本重定位，为什么ARMv7 NEON只显示一个文本重定位？
我正在readelf使用readelf -a <libame.a> | grep TEXTREL检查.a和.so个库。
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
如何找到在我的armv7neon .so库中引入文本重定位的罪魁祸首？
我使用的是NDK r12b。这是整个构建输出的一个pastebin：OK，没有pastie或者pastebin，因为他们不会允许2.1mb的文本。
大。那么，任何想法为什么文本重定位只出现在NEON？
问题可能与此问题类似，不过我也没有为x86重新定位。 Why is NDK generating shared library for x86 with text relocation even after setting -fPIC flag?
答案 0 :(得分：5)
如果使用-fPIC构建所有内容，则剩余的文本重定位通常在任何手写程序集中。
看起来ffmpeg的汇编代码有一些文本重定位问题：