我在Linux上开发了其他人共享的项目，并使用qt creator。
问题是我多次出现链接错误，特别是因为发生这种情况：
libA使用libB-> libA必须链接到libB
libC使用libA-> libC必须同时链接到libA和libB
appZ使用libC-> appZ必须链接到libC，libA和libB
对我来说，理想的情况是，我必须在appZ .pro文件中编写：“链接到libC”，然后自动获取其他依赖项。
这是因为经常发生有人更改一个库的依赖关系，并且许多难以修复的链接问题打招呼。
有没有办法设置qt创建者，使其仅指定最直接的依赖关系，如果可以，是否有任何缺点？还有其他选择吗？
我正在调查链接标志--no-undefined，但仍然不知道这是否对我有帮助。
[编辑]只是要澄清的问题是，如果100个应用程序使用libC，则如果libC或其依赖项之一必须链接到新库，这将成为一个大问题。必须更改所有应用程序，否则它们将具有链接问题。我只是在寻找一种方法来限制这个问题
答案 0 :(得分：1)
好的链接是一个广泛的话题，通常需要大量的时间和经验来理解所有内容。
要回答您的问题，没有人在一夜之间更改库或文件的依赖性。即使它们发生更改，它们也会提供先前版本以及新版本，并且它们与该库的先前版本具有向后兼容性（这意味着旧api可以使用）。如果他们添加了一些新的依赖关系以提供新的支持或功能，则会详细提供您需要的新文件以及如何构建该新库。
在许多情况下，如果您不需要任何新支持，请使用该库本身的旧版本。但是通常，新库中有一些错误修复，最好使用新版本。
我们使用库来减少工作量，但令人惊讶的是，我们增加了一些工作量来构建第三方库，跟踪这些库中的更改和错误，解决链接错误等。可悲的是，处理库并不容易比较Java还是npm。
我要做的是在Linux上编写一个脚本来跟踪所有内容，但是该脚本本身不是自动化的，但是可以减少很多工作量。我想您也可以做类似的事情。
只需澄清一下，问题是，如果100个应用程序使用libC，那么如果libC或其依赖项之一必须链接到新库，则将成为一个大问题。必须更改所有应用程序，否则它们将具有链接问题。我只是在寻找一种方法来限制这个问题
在这种情况下很容易，只需在构建机器中构建新库，然后在LD_LIBRARY_PATH中提供文件路径即可。我知道这并不容易，但是如前所述，与Java或npm相比，处理库并不容易。您可能还必须在用于维护构建的脚本中进行一些编辑。我看不到任何捷径。