我正在尝试为 ARM 重新编译一个适当大小的软件堆栈 (doubango)。两周后,我想我终于完成了,因为有文本重定位的库不再有 armeabi
了。 , armv5te
, armv7-a
.然而,armv7-a-neon
仍然有他们...
我知道链接包含文本重定位的静态库或共享库也会在我的库中引入它们,并且应该使用 -fPIC
来对抗它。在他的 CFLAGS 中重新编译所有内容以构建与位置无关的代码。完成所有这些后,我还构建了没有文本重定位的 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:好的,没有 pastie 或 pastebin,因为它们不允许 2.1mb 的文本。
太棒了。那么,为什么文本重定位只出现在 NEON 中?有什么想法吗?
这个问题可能与这个问题类似,只是我也没有 x86 的重定位。 Why is NDK generating shared library for x86 with text relocation even after setting -fPIC flag?
最佳答案
如果所有内容都是使用 -fPIC
构建的,则剩余的文本重定位通常位于任何手写程序集中。
看起来 ffmpeg 的汇编代码存在一些文本重定位问题:
- 关于 Android 错误跟踪器的报告(已关闭,不是 Android 错误):https://code.google.com/p/android/issues/detail?id=191235
- ffmpeg 错误:https://trac.ffmpeg.org/ticket/4928
- 另一个声称有修复的问题:https://stackoverflow.com/a/34697703/632035
关于android - 尽管有 -fPIC,但文本重定位?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39957435/