首页 > 解决方案 > 将未定义的引用错误限制为仅直接依赖项

问题描述

我在 Linux 上开发其他人共享的项目并使用 qt creator。

问题是我得到了很多次链接错误,特别是因为发生了这种情况:

libA 使用 libB -> libA 必须链接到 libB

libC 使用 libA -> libC 必须同时链接到 libA 和 libB

appZ 使用 libC -> appZ 必须链接到 libC、libA 和 libB

对我来说,理想的情况是在我的 appZ .pro 文件中我只需要写:“链接到 libC”,然后它会自动获取其他依赖项。

这是因为经常发生有人更改其中一个库的依赖关系并且许多难以修复的链接问题来打招呼..

有没有办法设置 qt creator 以仅指定最直接的依赖项,如果是,有什么缺点吗?其他选择?

我正在调查链接标志--no-undefined,但仍然不明白这是否对我有帮助。

[编辑] 澄清一下,问题是如果 100 个应用程序使用 libC,如果 libC 或其依赖项之一必须链接到新库,这将成为一个大问题。所有应用程序都必须更改,否则它们存在链接问题。我只是在寻找一种方法来限制这个问题

标签: c++linkershared-librarieslinker-errorsundefined-reference

解决方案


良好的链接是一个广泛的主题,通常需要大量的时间和经验来理解一切。

要回答您的问题,没有人会在一夜之间更改库或文件的依赖关系。即使它们发生变化,它们也会提供旧版本和新版本,并且它们提供与该库的先前版本的向后兼容性(意味着旧 api 将起作用)。如果他们添加了一些新的依赖项以提供新的支持或功能,他们会详细提供您需要哪些新的 so 文件以及如何构建该新库。

在许多情况下,如果您不想要任何新的支持,请使用该库本身的旧版本。但通常新库有一些错误修复,最好选择新版本。

我们使用库来减少工作量,但令人惊讶的是,我们增加了一些工作量来构建第三方库、跟踪这些库中的更改和错误、解决链接错误等。遗憾的是,处理库并不容易比较,以防万一在 Java 或 npm 中。

我所做的是在 Linux 中编写一个脚本来跟踪所有内容。但是该脚本本身不是自动化的,但它减少了我的大部分工作量。我想你也可以做类似的事情。

澄清一下,问题是如果 100 个应用程序使用 libC,如果 libC 或其依赖项之一必须链接到新库,这将成为一个大问题。所有应用程序都必须更改,否则它们存在链接问题。我只是在寻找一种方法来限制这个问题

在这种情况下很容易,只需在您的构建机器中构建您的新库,并在 LD_LIBRARY_PATH 中提供这样的文件路径。我知道这并不像说的那么容易,但正如前面提到的,与 Java 或 npm 相比,处理库并不容易。您可能还必须在用于维护构建的脚本中进行一些编辑。我没有看到任何捷径。


推荐阅读