将未定义的参考错误限制为仅直接依赖性

Limit undefined reference errors to only direct dependencies

本文关键字：依赖性 未定义 参考 错误      更新时间：2023-10-16

i在Linux上开发了其他人共享的项目并使用QT Creator。

问题是我链接错误了很多次，尤其是因为这发生了：

liba使用libb-＆gt;liba必须链接到libb

libc使用liba-＆gt;libc必须链接到liba和libb

appz使用libc-＆gt;Appz必须链接到LIBC，LIBA和LIBB

对我而言，理想是在我的appz .pro文件中，我必须写："链接到libc"。然后自动获得其他依赖项。

这是因为经常会发生某人改变其中一个libs的依赖关系，并且很难解决链接问题。

是否有任何方法可以通过某种方式设置QT创建者，以指定最直接的依赖性，如果是，是否有缺点？其他一些选择？

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

[编辑]只是为了澄清，问题是，如果100个应用使用libc，则如果LIBC或其依赖项之一必须链接到新库，则将成为一个大问题。.所有应用程序必须更改或它们有链接问题。我只是在寻找限制此问题的方法

Well链接是主题的广泛领域，通常需要大量的时间和经验来理解所有内容。

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

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

我们使用库减少工作量，但是令人惊讶的是，我们增加了一些工作量来构建第三方库，跟踪这些库中的更改和错误，解决链接错误等。可悲的是，与库打交道并不那么容易。在Java或NPM中进行比较。

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

只是为了澄清，问题是，如果100个应用使用LIBC，则如果LIBC或其依赖项之一必须链接到新库，则将成为一个大问题。.所有应用程序必须更改或它们链接问题。我只是在寻找一种限制此问题的方法

在这种情况下，很容易，只需在构建计算机中构建新库，然后在ld_library_path中提供SO文件路径。我知道这并不容易，但是如前所述，在Java或npm中，与图书馆打交道并不容易。您可能还必须在脚本中进行一些编辑，以维护构建。我看不到任何快捷方式。

相关文章：