我们有一些间接依赖的链接问题。从我在网上阅读的内容猜测，这可能是因为使用了两级命名空间。 当我们链接到 boost 库时会发生这种情况，确切地说是 boost_filesystem，它本身依赖于 boost_system。链接器不解决 boost_filesystem 和 boost_system 之间的依赖关系。 有人可以给我一些提示如何解决这个问题吗？手动将 boost_system 添加到依赖项中感觉很难看，此外，它在其他平台上也能正常工作。
【问题讨论】：
Mac 上某些版本的静态链接编辑器 ld 不会通过 -L 选项解析间接依赖关系，而是通过直接依赖关系中的 install_name 来查找它们。在 boost_filesysten 上运行 otool -L 会告诉你 ld 在哪里寻找 boost_system。
您可以使用 install_name_tool 更改 install_name，也可以使用
-dylib_file install_name:file_name
ld 的选项，这只是告诉 ld 每当遇到与冒号之前的参数部分匹配的 install_name 路径时，它实际上应该从冒号之后的路径中获取该库。
我认为新版本的 ld 现在确实尊重 -L 对 Mac 的间接依赖，但我不确定。我只使用了 10.4，它的 ld 忽略了 -L 用于间接依赖，我使用 -dylib_file 摆脱了许多其他人为了解决你描述的问题而放入的幻像显式依赖！
【讨论】：
如果 boost_filesystem 使用来自 boost_system 的符号（而您的应用程序不是），并且它本身直接链接到 boost_system 以解决它们，它应该可以正常工作。当您期望您链接的库的依赖项提供的符号在您的应用程序中可用时，平面与两级命名空间问题通常会出现。
如果 boost_filesystem 没有链接到 boost_system（otool -L 会告诉你），那么你几乎没有选择——除了重新链接它——除了手动添加对 boost_system 的依赖。
我认为 boost 不使用 GNU libtool 是否正确（它以正确的特定于平台的方式为您处理库间依赖关系）？如果是这样，那可能是一个简单的解决方法。
【讨论】：