【问题标题】:Is it necessary to use -l library option when using -c 'compile-only' option (and at what stage is fPIC option necessary)?使用 -c 'compile-only' 选项时是否需要使用 -l library 选项(以及在什么阶段需要 fPIC 选项)?
【发布时间】: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 进行编译,但我担心会触发一系列构建和集成测试失败的潜在错误。我没有为此代码编写特定的单元测试,并且对它们的覆盖率没有信心(我知道还有很多工作要做)

标签: c gcc


【解决方案1】:

-l 仅当您将对象链接到可执行或共享对象或直接编译为可执行或共享对象时才需要。但是使用 -c (“仅编译”)可以编译成目标文件,因此这里不需要 -l-fPIC - 您需要在编译成目标文件或直接编译成可执行文件时使用它。在链接阶段不需要它。所以你把它放在你也使用-c的地方。

【讨论】:

    猜你喜欢
    • 2014-03-20
    • 2016-07-17
    • 2011-04-15
    • 2016-06-11
    • 2014-12-30
    • 2019-08-10
    • 2013-05-18
    • 2013-12-26
    • 1970-01-01
    相关资源
    最近更新 更多