linux g++将 64 位共享库代码链接到静态库
上下文:我可以创建一个链接到静态库的共享对象库,在 32 位 Linux 上没有任何问题。当我在 64 位 Linux 上尝试相同的构建时,我看到这个链接器错误:
- 在创建共享对象时不能使用针对“本地符号”的重定位 R_X86_64_32S;使用 -fPIC 重新编译
此错误在网络上很常见。解决方案是使用位置无关代码(-fPIC)编译静态链接库。
我不明白为什么 32 位版本不需要这样做。有人可以帮忙吗?
Context: I can create a shared object library which is linked to a static library without any problems on 32bit linux. When I attempt the same build on 64bit linux, I see this linker error:
- relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
This error is quite common on the web. The solution is to compile the statically linked library with position independent code (-fPIC).
What I do not understand is why this is not required for the 32bit build. Can anyone help out?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您的目标模块将在共享库中使用,则始终需要“位置无关代码”。它高度依赖于平台,并且会产生一些开销。
您必须在 amd64(而非 x386)上显式指定它的原因很简单,因为它恰好是 x86(而非 amd64)的默认值。
还要注意“-fpic”和“-fPIC”之间的区别:
"Position Independent Code" is always required if your object module will be used in a shared library. It's highly platform dependent, and it incurs some overhead.
The reason you have to specify it explicitly on amd64, but not x386, is simply that it happens to be the default for x86, but not amd64.
Note, too, the difference between "-fpic" and "-fPIC":
好的,答案在这里详细描述: http://www.technovelty.org /code/c/amd64-pic.html。
解释的基本要点是 i386 体系结构隐式取消引用每个函数的帧指针(在链接页面的最后一段中进行了解释)。此过程会产生一些额外的开销,因此在新的 64 位架构中,这种取消引用的开销作为优化被消除了。
从链接的角度来看,这种优化的结果是,除非将 64 位代码显式编译为位置无关代码,否则它将生成带有其执行上下文偏移量的硬编码代码。
这是对链接页面内容的不完美解释,但足以满足我的目的。
Ok the answer is described in detail here: http://www.technovelty.org/code/c/amd64-pic.html.
The basic gist of the explanation is that the i386 architecture implicitly dereferences the frame pointer for each function (explained on the last paragraph of the linked page). This process incurs some extra overhead so in the new 64-bit architectures, this dereferencing overhead was eliminated as an optimization.
The consequence of this optimization from a linking perspective was that unless 64-bit code is explicitly compiled as position independent code, it will produce code that is hard-coded with offsets for its execution context.
This is an imperfect explanation of the content in the linked page but it suffices for my purposes.