我正在尝试将一些目标文件包含到正在构建的共享库中。采取以下命令(为简洁起见，省略了[ETC]中的内容):
因此，基本上我只是在创建一个共享库，其中大多数对象都来自我自己的源代码(即CMakeFiles/Valkka.dir/src/*。o)，但是其中一些来自外部静态库，位于“lib”/libavcodec.a”。我收到以下错误:
但这是不真实的!我可以用提取“libavcodec.a”
ar x libavcodec.a
然后检查
readelf --relocs h264_cabac.o | egrep '(GOT|PLT|JU?MP_SLOT)'
确实给出了一些**:
一样
objdump -r h264_cabac.o | grep -i "relocation"
因此，实际上，已经编译了“libavcodec.a”中的目标文件以获取PIC(与位置无关的代码)。
为什么链接器不这么认为!？
相关链接:
How to include all objects of an archive in a shared object?
Linking archives (.a) into shared object (.so)
Is there a way to determine that a .a or .so library has been compiled as position indepenent code?
How can I tell, with something like objdump, if an object file has been built with -fPIC?
最佳答案
TL； DR
将-Wl,-Bsymbolic添加到共享库的gcc链接选项。
为什么？
您正在使用以下命令测试h264_cabac.o的PICness:
readelf --relocs h264_cabac.o | egrep '(GOT|PLT|JU?MP_SLOT)
并得出结论，目标文件是使用
-fPIC编译的命中。大概是您从the favourite answer获得了此测试
到How can I tell, with something like objdump, if an object file has been built with -fPIC?
您获得了一些成功，我可以通过多种方式重现这一点:
来自源代码
$ git clone https://github.com/FFmpeg/FFmpeg.git
$ cd FFmpeg
$ ./configure --enable-shared
$ make
然后:
$ cd libavcodec
$ readelf --relocs h264_cabac.o | egrep '(GOT|PLT|JU?MP_SLOT)'
00000000175d 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000001926 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
00000000259f 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000002f0d 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000003216 003200000004 R_X86_64_PLT32 0000000000000000 av_log - 4
000000003460 00330000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_chroma422_dc_s - 4
000000003afc 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000003fb6 00360000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_i_mb_type_info - 4
000000004031 00370000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_mb_sizes - 4
00000000409a 003800000004 R_X86_64_PLT32 0000000000000000 ff_init_cabac_decoder - 4
000000004248 00390000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_b_mb_type_info - 4
000000004299 003a00000004 R_X86_64_PLT32 0000000000000000 ff_h264_pred_direct_mo - 4
000000004a31 003b00000004 R_X86_64_PLT32 0000000000000000 ff_h264_check_intra4x4 - 4
000000004bd5 003200000004 R_X86_64_PLT32 0000000000000000 av_log - 4
000000004f85 003c0000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_p_mb_type_info - 4
0000000050fd 003d0000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_b_sub_mb_type_ - 4
000000005233 003a00000004 R_X86_64_PLT32 0000000000000000 ff_h264_pred_direct_mo - 4
00000000544a 003200000004 R_X86_64_PLT32 0000000000000000 av_log - 4
000000005bef 003a00000004 R_X86_64_PLT32 0000000000000000 ff_h264_pred_direct_mo - 4
000000006db5 003e00000004 R_X86_64_PLT32 0000000000000000 ff_h264_check_intra_pr - 4
000000006de9 003f0000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_p_sub_mb_type_ - 4
000000007171 003200000004 R_X86_64_PLT32 0000000000000000 av_log - 4
000000008b1b 003e00000004 R_X86_64_PLT32 0000000000000000 ff_h264_check_intra_pr - 4
00000000ad41 004000000009 R_X86_64_GOTPCREL 0000000000000000 ff_h264_chroma_dc_scan - 4
00000000ad84 004000000009 R_X86_64_GOTPCREL 0000000000000000 ff_h264_chroma_dc_scan - 4
00000000b758 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
来自Ubuntu 16.04开发包
$ sudo apt-get install libavcodec-dev
$ dpkg -S libavcodec.a
libavcodec-dev:amd64: /usr/lib/x86_64-linux-gnu/libavcodec.a
$ mkdir ~/deleteme
$ cd ~/deleteme
$ ar x /usr/lib/x86_64-linux-gnu/libavcodec.a h264_cabac.o
$ readelf --relocs h264_cabac.o | egrep '(GOT|PLT|JU?MP_SLOT)'
0000000000c7 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
0000000002fa 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
00000000179d 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000001966 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000001b09 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000001d4a 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000001ee5 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
00000000265f 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000002fcd 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
0000000032f6 002f00000004 R_X86_64_PLT32 0000000000000000 av_log - 4
000000003305 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000003bdc 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000003cb5 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
000000004121 00320000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_mb_sizes - 4
000000004187 003300000004 R_X86_64_PLT32 0000000000000000 ff_init_cabac_decoder - 4
000000004381 003400000004 R_X86_64_PLT32 0000000000000000 ff_h264_pred_direct_mo - 4
000000004afe 003500000004 R_X86_64_PLT32 0000000000000000 ff_h264_check_intra4x4 - 4
000000005556 003400000004 R_X86_64_PLT32 0000000000000000 ff_h264_pred_direct_mo - 4
00000000576a 002f00000004 R_X86_64_PLT32 0000000000000000 av_log - 4
000000005acf 003400000004 R_X86_64_PLT32 0000000000000000 ff_h264_pred_direct_mo - 4
000000006e31 002f00000004 R_X86_64_PLT32 0000000000000000 av_log - 4
000000006e58 003600000004 R_X86_64_PLT32 0000000000000000 ff_h264_check_intra_pr - 4
000000009c20 003600000004 R_X86_64_PLT32 0000000000000000 ff_h264_check_intra_pr - 4
00000000b425 002f00000004 R_X86_64_PLT32 0000000000000000 av_log - 4
00000000b5ab 002e00000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
结果不完全相同，第一种方法获得26个重定位，第二种方法获得25个重定位。但是无论哪种方式，都有很多PIC安全的重定位
我很高兴相信
h264_cabac.o的两个编译都具有-fPIC，无论它们有其他选择。我要说明一个明显的问题:符号
ff_h264_cabac_tables，与之相关的链接提示:
relocation R_X86_64_PC32 against symbol 'ff_h264_cabac_tables' can not be used when making a shared object
不在任何一个列表中。这意味着该目标文件-来自两个来源-都包含PIC安全和PIC不安全的重定位。
在没有人注意的情况下，GCC怎么会出错？如果可以，如何
我刚刚运行了FFmpeg的共享库版本并成功链接了
libavcodec.so吗？让我们看一下PIC不安全的重定位:
$ readelf --relocs h264_cabac.o | egrep -v '(GOT|PLT|JU?MP_SLOT)'
000000000017 002c00000002 R_X86_64_PC32 0000000000000000 ff_h264_cabac_tables - 4
...
...
好吧，我将省略约160行，但是它们都描述了PC相关类型
R_X86_64_PC32搬迁和提及的唯一符号，折扣部分名称和本地标签，是我们的 friend
ff_h264_cabac_tables，符号表对此表示:$ readelf -s h264_cabac.o | grep ff_h264_cabac_tables
44: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND ff_h264_cabac_tables
这是一个全局变量，未在此目标文件中定义。
GCC的
-fPIC没有损坏。但是，知道目标文件是用-fPIC不能绝对保证它不包含PC相对类型引用未定义的全局符号的
R_X86_64_PC32重定位。 relocation R_X86_64_PC32 against symbol 'ff_h264_cabac_tables'是这样的搬迁。
R_X86_64_PC32类型重定位采用32位PC相对寻址模式，这是有效的，但在设置64位链接时有关键限制。
链接器不能保证引用的符号不会动态解析
到在此寻址模式下无法表示的地址。它不会有，所以
它说:
relocation R_X86_64_PC32 against symbol 'ff_h264_cabac_tables' can not be used when making a shared object
及其建议:
recompile with -fPIC
基于以下假设:罪魁祸首目标文件未使用
-fPIC进行编译。这可能是(但必然是)正确的假设，而关于
您的罪魁祸首
libavcodec.a(h264_cabac.o)使用
-fPIC进行编译将确保您能够进行PIC安全的重定位，前提是该编译器允许进行所有汇编和代码生成。但这是不允许的
与您的
h264_cabac.o标本或我的任何一个标本一起使用。所有这些标本是从FFmpeg源代码树中的
FFmpeg/libavcodec/x86/h264_cabac.c编译的。查看该文件，您将看到它定义了引用
extern的函数全局变量
ff_h264_cabac_tables，并以内嵌手工方式实现部件。可以告诉GCC编译这些函数
-fPIC，但是没有得到一个机会。这些功能的位置独立性是
汇编代码的作者。
我们可以证明GCC能够编译只有PIC安全的
h264_cabac.o搬迁，如果允许的话。这将附带证明您的联系失败源于我们对文件样本的手工组装，还将显示
您可以解决链接失败的问题。 FFmpeg的
./configure脚本具有以下选项:--disable-asm disable all assembly optimizations
除其他功能外，这会导致编译
h264_cabac.o从纯C源文件FFmpeg/libavcodec/h264_cabac.c而不是内联汇编源
FFmpeg/libavcodec/x86/h264_cabac.c。因此，我们尝试:$ cd FFmpeg
$ make clean
$ ./configure --enable-shared --disable-asm
$ make
$ cd libavcodec
$ readelf --relocs h264_cabac.o | grep ff_h264_cabac_tables
00000000000a 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
0000000000ca 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
000000001eb5 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
0000000021c6 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
0000000026fe 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
000000002a17 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
000000002f13 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
00000000324c 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
000000003509 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
00000000362a 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
0000000037d7 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
00000000592b 00300000002a R_X86_64_REX_GOTP 0000000000000000 ff_h264_cabac_tables - 4
现在，所有引用
ff_h264_cabac_tables的重定位都是PIC安全的。我们不妨证明该
h264_cabac.o可以在共享库中链接。我们知道该
ff_h264_cabac_tables在h264_cabac.o中未定义，因此我们还需要链接定义它的目标文件。碰巧是
./cabac.o。$ gcc -shared -o libfoo.so h264_cabac.o cabac.o
瞧:
$ file libfoo.so
libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ed63107b715b357853da94d4a031c0b06c30c5f2, not stripped
但是，如果您必须链接自己的链接，可能仍会感到有些委屈
这个未优化的
h264_cabac.o的共享库，但有些令人失望强制您执行的汇编编码缺陷。这些感觉为时过早。
记住，我已经使用普通 Vanilla
./configure --enable-shared成功构建了FFmpeg。我说过链接器在您失败的链接中的异议是
R_X86_64_PC32如果ff_h264_cabac_tables，在运行时引用ff_h264_cabac_tables的重定位可能不可行是动态解决的。它不是对
R_X86_64_PC32类型的反对这样的搬迁。基于对
ff_h264_cabac_tables的无知，这是一个预防性反对最终将得到解决。
但是我们知道
ff_h264_cabac_tables实际上是在cabac.o中定义的，我们将把它与
h264_cabac.o包括在内，就像它们都被包括在内一样在
libavcodec.so的链接中。我们可以告诉链接器，任何全局链接中的引用应静态解析为
通过传递参数来链接共享库(如果有的话):
-Bsymbolic
这将消除对
R_X86_64_PC32重定位的预防性反对。它知道它将能够在链接时决定
R_X86_64_PC32根据ff_h264_cabac_tables进行重定位是可行的。如果没有，它将给一个不同的错误:
relocation truncated to fit:..。否则它将成功没有评论。
不可避免地，这就是在库存FFmpeg构建中成功链接
libavcodec.so的方式。从顶部再次:
$ cd FFmpeg
$ make clean
$ ./configure --enable-shared
$ make
然后强制重新链接
libavcodec.so:$ rm libavcodec/h264_cabac.o
$ $ make libavcodec/libavcodec.so V=1
gcc -I. -I./ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE \
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DZLIB_CONST -DHAVE_AV_CONFIG_H \
-std=c11 -fomit-frame-pointer -fPIC -pthread -g -Wdeclaration-after-statement \
-Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings \
-Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes \
-Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign \
-O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security \
-Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type \
-Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized \
-MMD -MF libavcodec/h264_cabac.d -MT libavcodec/h264_cabac.o -c \
-o libavcodec/h264_cabac.o libavcodec/h264_cabac.c
sed 's/MAJOR/57/' libavcodec/libavcodec.v | cat > libavcodec/libavcodec.ver
gcc -shared -Wl,-soname,libavcodec.so.57 -Wl,-Bsymbolic ... etc. etc. ...
^^^^^^^^^^^^^^
因此，没有汇编编码缺陷。链接手动优化的
h264_cabac.o在共享库中，您只需要将-Wl,-Bsymbolic添加到gcc链接选项。它是优化的要求。
让我们至少证明一下:
$ cd libavcodec/
$ gcc -shared -o libfoo.so h264_cabac.o cabac.o
/usr/bin/ld: h264_cabac.o: relocation R_X86_64_PC32 against symbol `ff_h264_cabac_tables' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
再次有失败。和:
$ gcc -shared -Wl,-Bsymbolic -o libfoo.so h264_cabac.o cabac.o
$ file libfoo.so
libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7dc86aeae353c4d92cdb5fa35d169bf019b47eb2, not stripped
成功。