如果使用gcc -fPIC标志,如果它们在可执行文件中使用,会产生什么影响? [英] What, if any, are the implications of compiling objects with gcc -fPIC flag if they get used in executables?

查看:214
本文介绍了如果使用gcc -fPIC标志,如果它们在可执行文件中使用,会产生什么影响?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在为我正在开发的一个项目组建一个makefile。我在项目中有一个可执行文件和一个共享库。两者都使用一些单独编译到目标文件中的相同源文件。为了能够在共享库中使用这些对象,我需要在gcc中使用-fPIC(位置独立代码)标志。是否有用-fPIC编译对象的影响?

解决方案

在不需要时编译与位置无关的代码是一些平台上的性能拖延(最值得注意的是,由于PIC取消了一个在非PIC时可以更自由使用的寄存器),但不应该有其他不利影响。 b
$ b

更进一步,甚至可以创建一个与位置无关的代码构建的独立于位置的可执行文件( -fPIE )。

这就是说, libtool 可以为编译的每个源文件自动生成PIC和非PIC对象,即使在没有libtool集成的构建系统中也应该很容易做到。


I am putting together a makefile for a project i am working on. I have an executable and a shared library in the project. Both use some of the same source files which get compiled separately into object files. To be able to use these objects in the shared library I need to use the -fPIC (position independent code) flag in gcc. Are there any implications of compiling objects with -fPIC that get used in a executable?

解决方案

Compiling position-independent code when not necessary is a performance drag on some platforms (most notably, the register-starved x86 architecture, because PIC takes away a register that can be used more freely when non-PIC), but there should be no detrimental effects otherwise.

Going further, it is even possible to create a position-independent executable (-fPIE) built out of only position-independent code.

That being said, libtool can automatically produce both PIC and non-PIC objects for each source file you compile, and it should be easy to do the same even in a build system without libtool integration.

这篇关于如果使用gcc -fPIC标志,如果它们在可执行文件中使用,会产生什么影响?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆