找出为什么 cmake 添加特定的链接标志答案

【问题标题】：Find out why cmake adds specific link flags找出为什么 cmake 添加特定的链接标志
【发布时间】：2021-12-28 09:00:33
【问题描述】：

我有一个使用 cmake 的大项目。它主要工作。但是最近一些编译服务器与测试服务器的组合坏了。调查发现最终编译/链接命令调用gcc (...) -licudata -licui18n -licuuc (...)，这引入了对测试服务器上不存在的共享库的依赖。

如何找出我的项目（我的库、导入的库、找到的库，等等）中添加了这 3 个标志到编译命令的内容？

我没有明确添加它们，所以某些事情是自动完成的，我想找到它。 compile_commands.json 没有它们，因为链接标志不属于其中。 CMakeCache.txt 在一些不起眼的变量 PC_LIBXML_STATIC_LIBRARIES:INTERNAL 中有这些标志，但在那里删除它们不会影响编译/链接命令。

请注意，这个问题不是关于专门处理 libicu，而是关于一般调查方法（尽管关于 libicu 最终已知问题的 cmets 也会受到赞赏）。

【问题讨论】：

目标可能并且确实会引入标志。如果您正在导入第 3 方，您可以查找 PkgConfig.cmake 或 FindPkg.cmake 脚本（Pkg - 包名称，如 find_package）并调查哪些标志添加到这些目标
stackoverflow.com/a/56158485/9363996 这个答案建议了一种很好的调试技术，即为目标添加自定义命令并打印出标志。这样您就可以提高调查效率

标签： cmake dynamic-linking

【解决方案1】：

我发现由 cmake 创建的依赖图可以包含为我们的项目配置的更多详细信息。以下是所有选项：https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html 我希望 GRAPHVIZ_EXTERNAL_LIBS、GRAPHVIZ_SHARED_LIBS 设置为 true 是最重要的。

我们启用了所有可能启用的功能，没有过滤任何内容，结果图非常庞大（对于 xdot 来说太大了 - 幸运的是 .dot 文件是人类可读的），但表明 Boost::regex 使用了这 3 个库。

【讨论】：