将64位共享库代码链接到静态库的Linux g++问题

Question

将64位共享库代码链接到静态库的Linux g++问题

linux64-bitg++linker32-bit

9

背景: 在32位Linux上，我可以创建一个静态库链接到共享对象库而不会出现问题。当我在64位Linux上尝试进行相同的构建时，我看到了这个链接器错误:

重定位R_X86_64_32S与“本地符号”不能在创建共享对象时使用; 请使用-fPIC重新编译。

这个错误在网上非常常见。解决方法是使用位置无关代码(-fPIC)编译静态链接库。

我不明白为什么32位版本不需要这样做。有人能帮忙解释一下吗？

- Gearoid Murphy

2个回答

4

好的，答案在这里有详细描述：http://www.technovelty.org/code/c/amd64-pic.html。

简要概述一下，i386体系结构隐式地为每个函数解引用帧指针（在链接页面的最后一段说明）。这个过程会产生一些额外的开销，因此在新的64位体系结构中，这个解引用开销被消除作为一种优化。

从链接的角度来看，这种优化的结果是，除非64位代码显式编译为位置无关代码，否则它将生成硬编码了执行上下文偏移量的代码。

这是对链接页面内容的不完美解释，但对我的目的足够了。

- Gearoid Murphy

还与此相关的是https://dev59.com/tHA75IYBdhLWcg3ws7ci。 - Gearoid Murphy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- paulsm4 · Accepted Answer

如果您的目标模块将在共享库中使用，“位置无关代码”始终是必需的。它高度依赖于平台，并且会增加一些开销。

您需要在amd64上显式指定它的原因是它是x86的默认值，但不是amd64的默认值。

还要注意“-fpic”和“-fPIC”的区别：

-fpic
    Generate position-independent code (PIC) suitable for use in a 
    shared library, if supported for the target machine. Such code 
    accesses all constant addresses through a global offset table 
    (GOT). The dynamic loader resolves the GOT entries when the pro-
    gram starts (the dynamic loader is not part of GCC; it is part
    of the operating system). If the GOT size for the linked execu-
    table exceeds a machine-specific maximum size, you get an error 
    message from the linker indicating that -fpic does not work; in 
    that case, recompile with -fPIC instead. (These maximums are 8k 
    on the SPARC and 32k on the m68k and RS/6000. The 386 has no 
    such limit.)

    Position-independent code requires special support, and there
    fore works only on certain machines. For the 386, GCC supports 
    PIC for System V but not for the Sun 386i. Code generated for 
    the IBM RS/6000 is always position-independent.

    When this flag is set, the macros __pic__ and __PIC__ are defined to 1.

-fPIC
    If supported for the target machine, emit position-independent 
    code, suitable for dynamic linking and avoiding any limit on the 
    size of the global offset table. This option makes a difference 
    on the m68k, PowerPC and SPARC.

    Position-independent code requires special support, and therefore 
    works only on certain machines.

    When this flag is set, the macros __pic__ and __PIC__ are defined to 2.