首页 文章

linux g将64位共享库代码链接到静态库

提问于
浏览
8

上下文:我可以创建一个链接到静态库的共享对象库,在32位linux上没有任何问题 . 当我在64位linux上尝试相同的构建时,我看到了这个链接器错误:

在制作共享对象时,不能使用

  • 重定位R_X86_64_32S对“本地符号”;用-fPIC重新编译

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

我不明白为什么32bit版本不需要这样做 . 任何人都可以帮忙吗?

2 回答

  • 4

    如果您的目标模块将在共享库中使用,则始终需要“位置无关代码” . 它依赖于高度平台,并且会产生一些开销 .

    您必须在amd64上明确指定它而不是x386的原因只是它恰好是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.
    
  • 4

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

    解释的基本要点是i386架构隐式取消引用每个函数的帧指针(在链接页面的最后一段解释) . 此过程会产生一些额外开销,因此在新的64位体系结构中,这种解除引用开销作为优化被消除 .

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

    这是对链接页面中内容的不完美解释,但它足以满足我的目的 .

相关问题