【发布时间】:2021-07-20 20:50:53
【问题描述】:
我在清理一些 makefile 时经常遇到这种情况。这只是懒惰的makefile工艺还是在调用仅编译-c选项时-l选项有目的?
对于进一步的上下文:假设foo.c 确实使用了libbar.so 中的某些功能。但是,在使用-c 选项编译foo.c 时,是否需要包含-lbar 或者仅包含bar.h 的必要路径就足够了?对于更进一步的上下文,假设foo.o 将在稍后阶段与其他一些输出捆绑在一起,然后将调用“-lbar”选项。我不确定这是否重要,但我还要规定 libbar.so 是自定义库或其他非系统库。
我意识到我可能犯了张贴犯规,但这是一个相关的问题:在上述过程中何时需要-fPIC 选项?我可以等到将foo.o 与其他相关的输出文件以及前面提到的'-lbar' 选项捆绑在一起,还是在首次编译foo.c 时需要'fPIC',即使我正在使用-c 选项?
【问题讨论】:
-
-l仅在链接时使用。来自man gcc:“链接时搜索名为 library 的库。[...] -l 选项由 GCC 直接传递给链接器。”。因此,如果您不链接,则无需指定-l。 -
实验是一种很好的学习方式。从
-c命令行中删除-l会发生什么?有什么坏的吗? -
SO 选择了大写 I(如 Indigo)与小写 l(如 in love)绝对无法区分的字体,这一事实使问题变得超级混乱。
-
-fPIC表示“生成与位置无关的代码”,因此是编译器标志,因此在使用-c编译时包含它 -
关于实验问题:是的,我做了一些实验;到目前为止,事情确实使用
-c选项而不使用-l进行编译,但我担心会触发一系列构建和集成测试失败的潜在错误。我没有为此代码编写特定的单元测试,并且对它们的覆盖率没有信心(我知道还有很多工作要做)