我在 Linux 上使用其他人共享的项目并使用 qt creator 进行开发。
问题是我多次遇到链接错误，尤其是因为发生了这种情况:
libA uses libB -> libA must link to libB
libC uses libA -> libC must link to both libA and libB
appZ uses libC -> appZ must link to libC, libA and libB
对我来说，理想的情况是在我的 appZ .pro 文件中我只需要写:“链接到 libC”，然后它会自动获取其他依赖项。
这是因为经常有人更改其中一个库的依赖项，并且许多难以修复的链接问题来打招呼..
有没有办法设置qt creator只指定最直接的依赖关系，如果有，有什么缺点吗？其他选择？
我正在调查链接标志 --no-undefined 但仍然不明白这是否对我有帮助。
[编辑] 澄清一下，问题是如果 100 个应用程序使用 libC，如果 libC 或其依赖项之一必须链接到新库，这将成为一个大问题。所有应用程序都必须更改，否则它们会出现链接问题.我只是在寻找一种方法来限制这个问题
最佳答案
链接是一个广泛的话题，通常需要大量的时间和经验才能理解所有内容。
要回答您的问题，没有人会在一夜之间更改库或 so 文件的依赖项。即使它们发生变化，它们也会提供以前的版本和新版本，并且它们提供与该库的以前版本的向后兼容性(这意味着旧的 api 可以工作)。如果他们添加了一些新的依赖项以提供新的支持或功能，他们会详细提供您需要哪些新的 so 文件以及如何构建该新库。
在许多情况下，如果您不需要任何新支持，请使用该库本身的旧版本。但通常新库会修复一些错误，最好还是使用新版本。
我们使用库来减少我们的工作量，但令人惊讶的是，我们增加了一些工作量来构建第三方库，跟踪这些库中的更改和错误，解决链接错误等。遗憾的是，与库打交道并不容易比较 Java 或 npm 中的大小写。
我所做的是在 Linux 中编写一个脚本来跟踪所有事情。但是该脚本本身并不是自动化的，但它减少了我的大部分工作量。我认为您也可以做类似的事情。
Just to clarify, problem is that if 100 apps use libC, it becomes a big problem if libC or one of its dependencies must link to a new library.. all the applications must be changed or they have linking problems. I am just looking for a way to limit this problem
在这种情况下很容易，只需在构建机器中构建新库，并在 LD_LIBRARY_PATH 中提供文件路径。我知道这并不像说的那么容易，但是如前所述，与 Java 或 npm 相比，处理库并不容易。您可能还必须在用于维护构建的脚本中进行一些编辑。我看不到任何捷径。
关于c++ - 将 undefined reference 错误限制为仅直接依赖，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54941855/