使用预编译头重构项目中某些文件的依赖关系会导致链接器错误

发布于 2024-07-25 21:37:31 字数 946 浏览 8 评论 0原文

我正在使用 MSVC++ 6 构建一个非常大的项目。 该项目中的一些源文件与我们用于维护应用程序的小型实用程序共享。 以前,这个小实用程序需要链接主应用程序中的许多库,并且在运行时还需要主应用程序的 DLL。 我的任务是删除这些依赖项,这听起来很简单......不幸的是,主应用程序中使用的预编译头给我带来了很多麻烦。

我首先重新设计了实用程序中的所有文件,以明确包含它们所需的所有内容,然后删除了 PCH 的 #include 指令(这删除了该实用程序 95% 的不必要的依赖项)。 这对于编译该实用程序非常有用。 然而,现在编译主应用程序会出现有关缺少预编译头指令的错误。 我想“太好了,我只是有条件地包括 PCH”。 这似乎不起作用...我得到“意外的#endif”,如上所述 此处。 我的下一个想法是在主应用程序中关闭实用程序和主应用程序之间共享的三个源文件的 PCH。 编译成功,但在链接过程中出现了一堆如下所示的错误:

tls7d.lib(tls707d.dll) : error LNK2005: "public: unsigned int __thiscall RWCString::length(void)const " (?length@RWCString@@QBEIXZ) already defined in stripledescypher.obj

AFAICT,所有多重定义的符号都是我明确包含在共享文件中以避免需要 PCH 的符号。 我的预感是,由于我将这 3 个文件链接到与 PCH .cpp 文件相同的 DLL 中,因此它们在多个位置进行编译。 有什么办法摆脱这个混乱吗? 我会尝试任何事...

I'm using MSVC++ 6 to build a very large project. Some of the source files in this project are shared with a small utility that we use for maintaining the application. Previously, this small utility required linking against many libs from the main app and also required the main app's DLLs at runtime. I was tasked with removing these dependencies, which sounded pretty simple... unfortunately, the precompiled headers used in the main app are causing me a lot of trouble.

I first reworked all the files in the utility to explicitly include everything they need and then I removed the #include directives for the PCH (this removed 95% of the unnecessary dependencies for the utility). This works great for compiling the utility. Now, however, compiling the main app gives me errors about missing precompiled header directives. I thought "great, I'll just conditionally include the PCH". This does not seem to work... I get "unexpected #endif", as mentioned here. My next thought was to turn off PCH in the main app for the three source files that are shared between the utilty and the main app. This compiles successfully, but I get a bunch of errors that look like this during linking:

tls7d.lib(tls707d.dll) : error LNK2005: "public: unsigned int __thiscall RWCString::length(void)const " (?length@RWCString@@QBEIXZ) already defined in stripledescypher.obj

AFAICT, all of the multiply defined symbols are ones that I explicitly include in the shared files to avoid the need for the PCH. My hunch is that since I'm linking those 3 files into the same DLL as the PCH .cpp file, they're compiled in multiple places. Is there any way out of this mess? I'll try just about anything...

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

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

发布评论

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

评论(1

So尛奶瓶 2024-08-01 21:37:31

当编译器在处理编译单元时发现符号X的定义时,它会为链接器创建一个提示:X在这里!

两个源文件的编译,都使用定义(即不仅仅是声明)来#include标头,将导致两个目标文件定义相同的符号。 链接器将找到一个多重定义的符号。

因此,您的 stripledescypher 对象文件似乎包含 WCString::lenght()const 方法的定义。 这可能是由于函数体被定义在类的头文件或类似的东西中。

When the compiler finds a definition of a symbol X when processing a compilation unit, it will create a hint for the linker: X is in here!

The compilation of two source files, both #includeing a header with a definition (i.e. not a mere declaration) will result in two object files defining the same symbol. The linker will find a symbol multiply defined.

So it appears that your stripledescypher object file includes a definition of the WCString::lenght()const method. This may be due to the function body being defined in the class' header or something the like.

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