为什么 Bazel 欠链接，我该如何解决？答案

【问题标题】：Why does Bazel under-link and how do I fix it?为什么 Bazel 欠链接，我该如何解决？
【发布时间】：2017-06-23 14:25:45
【问题描述】：

我正在尝试使用 Bazel 构建和打包 LCM。这适用于“构建”部分，但最终结果是外部消费者无法使用库（即“包”失败，因为包已损坏）。

LCM 使用 glib，我使用 pkg_config_package (gory details) 导入它。更具体地说，LCM 在内部使用 glib，但不向用户公开。这意味着消费者不需要链接 glib； liblcm.so 应该这样做，消费者应该只需要链接到 LCM 本身。

这一切都适用于上游（使用 CMake 并做正确的事）。然而，由于某些未知原因，Bazel 似乎没有将liblcm.so 链接到 glib。如果我在同一个整体环境中使用 Bazel 构建可执行文件，Bazel 似乎知道 LCM 的用户也需要链接到 glib。但是，当我尝试打包这个 LCM 以供外部使用时，它坏了，因为liblcm.so 没有链接到 glib，这迫使消费者处理 LCM 的 private glib 依赖。

为什么 Bazel 没有将 LCM 库链接到 glib，我该如何解决？

（p.s. 我们与 libbot 有类似的问题...）

【问题讨论】：

标签： bazel

【解决方案1】：

显然，这是一个已知问题：https://github.com/bazelbuild/bazel/issues/492。

我也不能只将cc_library 设为cc_binary，因为——虽然这会修复欠链接——但我不能在其他 Bazel 目标中使用该库。我也不能制作一个包装cc_library 的cc_binary，因为这样内部和外部消费者就不会使用同一个库。

【讨论】：

好吧，严格来说不是这样，尽管有点骇人听闻 - 你仍然可以将 .so 放入 cc_library/cc_binary 的 srcs 中，它会起作用（这是让 bazel 了解预编译库的当前机制）。但这还不够表达，这就是为什么我们致力于问题 #492 中提到的“传递库”。总而言之，bazel 在“开源世界的开发”领域还有很多需要改进的地方。

【解决方案2】：

静态库不与其他静态库链接。通过 Bazel 构建时，Bazel 会跟踪依赖关系，并在构建可执行文件时链接所有依赖库。

这里有更多关于链接静态库的信息： Linking static libraries to other static libraries

提出的一个有趣的建议是取消归档这两个库，然后创建一个包含所有 .o 文件的新库。这可能会在一个类中实现。

【讨论】：

我没有生产静态库...这种行为对于共享库来说是错误的并且被破坏了。您是说 Bazel 由于 sojme 静态库遗留问题而无法生成完整的共享库吗？
现有行为无法生成供外部使用的共享库。它可以使 TDD 往返更快，例如编辑测试时，仅重新编译和重新链接测试，而不是依赖项。在许多情况下，测试与所有依赖项的静态链接将比测试链接 + 加载花费更多的时间。