代码之家 › 专栏 › 技术社区 › Hassan Syed

为什么GCC在x86_64上编译静态库时不隐式提供-fpic标志?

gnu-toolchain static-linking dynamic-linking compilation gcc

55

Hassan Syed · 技术社区 · 14 年前

我在编译静态链接到静态库的共享对象时遇到了许多问题。这个问题只出现在x84_64平台上。在x86上执行相同的编译工作时,我没有任何问题。

也许这是一个特定于操作系统的GCC配置,但我的研究表明GCC是如何在x86_64平台上工作的。无论如何,我在Ubuntu10.04 x86_64上使用GCC4.4.3。

如何解决问题?…确保使用-fpic编译所有静态库依赖项。

问题1: -fpic和-fpic的区别是什么(显然-fpic在x86上生成更多指令)?为什么后面的类型在x86_64上下文中更相关?

问题2: 我的假设是,当您针对静态代码进行链接时,您在链接时将函数硬连接到二进制文件中,为什么它需要“位置独立代码”机制提供的间接级别?

问题3: 现在,如果x86不需要-fpic/-fpic将共享对象与静态存档链接,为什么需要在x86_64中?

问题4: 即使需要,为什么不隐式提供?我认为打破改变应该是一个大的不不

1 回复 | 直到 14 年前

1

44

Community CDub 7 年前

看到问题 3544035 . 还讨论 here 和 there .
这取决于您将对静态库使用什么。如果您只想将它链接到程序中,那么它不需要pic代码(libtool称之为方便库,因为您几乎可以不用它,它只是帮助您的编译过程达到一个合理的大小,例如)。否则,如果您打算将共享库与之链接,则需要在静态库中使用pic代码。
看到问题 3146744 而且 here
它会使代码膨胀,所以它不是默认值。要看到的一件事是,当您编译单个对象文件时,GCC不知道您是否要用它创建一个共享库。在我大多数较小的项目中,我只是将几个对象文件链接在一起,例如,不需要pic代码。

另外,我的建议是:如果你需要担心的话,那就是你做错事了(或者你喜欢学习困难的方法,这很好,因为你会从中得到更多的经验)。编译系统(libtool、cmake,无论您使用什么)都应该为您做到这一点。