是否有一个自动程序可以找到 C++链接器错误?

发布于 2024-08-13 05:36:10 字数 466 浏览 7 评论 0原文

我正在使用 C++ 的 Linux 环境中工作,使用 GCC 编译器。

我目前正在修改和升级大量现有的代码。作为其中的一部分,有必要在整个代码的不同位置添加大量的小引用以将事物链接在一起,并且还添加几个新的外部代码库。还有一个相当大且复杂的 Makefile 结构链接到configure.ac 文件来处理构建过程。

开始构建过程后,所有内容都可以正常编译,但在尝试使用我们创建的新添加的自定义代码库时,会出现可怕的链接器错误。现在,我们已经仔细检查了大量代码,查找拼写不匹配的地方,检查所有库包含在构建过​​程中的顺序,并使用转储检查创建的 .o 文件是否包含我们需要的内容,以及一切都在它们应该在的地方。我们还单独测试了该库,问题肯定不在那里。

简而言之,我们已经尝试了在这些场景中通常应该做的大部分事情。

是否有一个 C++ 工具可以自动检测链接器错误,类似于 cppcheck 或 splint(这两个工具我们都运行无济于事)可以在这里提供帮助?

I'm working in a Linux environment with C++, using the GCC compiler.

I'm currently working on modifying and upgrading a large pre-existing body of code. As part of this, it has been necessary to add quite a large number of small references throughout the code in a variety of places to link things together, and also to add in several new external code libraries. There is also quite a large and complex structure of Makefiles linked to a configure.ac file to handle the build process.

Upon starting the build process everything compiles without a problem, but comes back with the dreaded linker error when trying to use a newly added custom code library we've created. We have now been through a vast amount of code with a fine tooth comb looking for spelling mismatches, checking the order that all the libraries are included in the build process, and checked that the .o files created contain what we need using dumps, and all are as and where they should be. We've also tested the library separately and the problem definitely doesn't lie there.

In short, we've tried most things that you should normally do in these scenarios.

Is there a tool for C++ that can detect linker errors automatically, in a similar vein to cppcheck or splint (both of which we have run to no avail) that could help here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

悲歌长辞 2024-08-20 05:36:10

不知道你的平台,但我花了一些时间来解决 gcc 中的链接器问题,直到我意识到静态库(.a)链接需要特定的顺序,它与链接 gcc 对象不同.o first.a secondary.agcc object.o secondary.a first.a 更重要。

Don't know your platform, but I spent sometime with linker problems in gcc till I realized that the static library (.a) linking requires specific ordering, its not the same to link gcc object.o first.a second.a than gcc object.o second.a first.a.

一指流沙 2024-08-20 05:36:10

FWIW(不多)我尝试通过使用另一个链接器来解决此类问题,因为我可以访问几个不同的平台。如果您可以使用另一个链接器,您将发现:

a)程序链接,这将您的问题从“为什么不链接?”转变为“为什么不链接?”到“链接器和链接之间有什么区别?”这并不完全是向前迈出的一步,但有时向一边迈出一步会给你带来不同的视角,从中你可以看到解决方案;

或者

b) 它无法链接,在这种情况下,另一个链接器可能会提供有关其失败原因的更多有用信息。

FWIW (not much) I try to tackle this sort of issue by using another linker as I have access to a couple of different platforms. If you can use another linker you will find either:

a) the program links, which transforms your problem from 'why doesn't it link ?' to 'what are the differences between linkers and linking ?' which isn't exactly a step forward, but sometimes a step to one side gives you a different perspective from which you can see a solution;

OR

b) it fails to link, in which case the other linker might give more useful information about why it fails.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文