C++ 关于不一致的dll链接
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2592523/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
About inconsistent dll linkage
提问by baris.aydinoz
How can I remove this link warning? You can see code segment that causes this warning.
如何删除此链接警告？您可以看到导致此警告的代码段。
static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };
//bla bla
// Exported DLL initialization is run in context of running application
extern "C" void WINAPI InitGuiCtrlsDLL()
{
// create a new CDynLinkLibrary for this app
new CDynLinkLibrary(GuiCtrlsDLL);
// nothing more to do
}
warning C4273: 'InitGuiCtrlsDLL' : inconsisten t dll linkage
警告 C4273：“InitGuiCtrlsDLL”：DLL 链接不一致
I have also export and import definitions, like:
我还有导出和导入定义，例如：
#ifdef _GUICTRLS
#define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
#define GUI_CTRLS_EXPORT __declspec(dllimport)
#endif
采纳答案by G?khan Akca
There are multiple possibilities:
有多种可能：
1) static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };
1) static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };
You use AFX_EXTENSION_MODULE. This means that you are implementing an MFC extension DLL. For such extension dlls you have to define the preprocessor _AFXEXT. Set this in the C++ compiler settings of your Visual C++ project
您使用 AFX_EXTENSION_MODULE。这意味着您正在实现 MFC 扩展 DLL。对于此类扩展 dll，您必须定义预处理器 _AFXEXT。在 Visual C++ 项目的 C++ 编译器设置中设置此项
see:
看：
How To Use _declspec(dllexport) in an MFC Extension DLL: http://support.microsoft.com/kb/128199
如何在 MFC 扩展 DLL 中使用 _declspec(dllexport)：http: //support.microsoft.com/kb/128199
AFX_EXTENSION_MODULE Structure: http://msdn.microsoft.com/en-us/library/sxfyk0zk.aspx
AFX_EXTENSION_MODULE 结构：http: //msdn.microsoft.com/en-us/library/sxfyk0zk.aspx
TN033: DLL Version of MFC: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx
TN033：MFC 的 DLL 版本：http: //msdn.microsoft.com/en-us/library/hw85e4bb.aspx
2) It is likely that you have a duplicated definiton/declaration.
2) 您可能有重复的定义/声明。
回答by Eric Thompson
The purpose of the preprocessor statements:
预处理器语句的目的：
#ifdef _GUICTRLS
#define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
#define GUI_CTRLS_EXPORT __declspec(dllimport)
#endif
is to make sure that the header file declares the class or function as __declspec(dllexport) in the .dll where it is defined, and as __declspec(dllimport) for any other .dll that might want to use it.
是确保头文件在定义它的 .dll 中将类或函数声明为 __declspec(dllexport)，并为可能想要使用它的任何其他 .dll 声明为 __declspec(dllimport)。
For this to work, _GUICTRLS must be defined when compiling the exporting .dll, and not defined for any other .dll. Generally you would expect _GUICTRLS to be defined in the project properties, under C/C++ -> Preprocessor -> Preprocessor Definitions.
为此，必须在编译导出 .dll 时定义 _GUICTRLS，而不是为任何其他 .dll 定义。通常，您希望在项目属性中定义 _GUICTRLS，在 C/C++ -> Preprocessor -> Preprocessor Definitions 下。
The compiler error you are seeing usually happens because either _GUICTRLS is not defined for the project that is doing the export, or it is defined for multiple projects, usually resulting from cutting an pasting from one project to another. You will also see this if _GUICTRLS is defined in a header file that is included in multiple projects.
您看到的编译器错误通常是因为 _GUICTRLS 没有为执行导出的项目定义，或者它是为多个项目定义的，通常是由于从一个项目剪切粘贴到另一个项目。如果 _GUICTRLS 在包含在多个项目中的头文件中定义，您也会看到这一点。
回答by Matteo Italia
That warning is usually caused by a duplicate definition of a function with different use of dllimport. Are you sure you didn't do this?
该警告通常是由具有不同 dllimport 用法的函数的重复定义引起的。你确定这不是你做的？
回答by Ivan
In addition to reading the warning message, pay attention to where it occursif you have multiple projects as part of a workspace.
除了阅读警告消息之外，如果您有多个项目作为工作区的一部分，请注意它出现的位置。
I wasted time looking for a problem in my DLL which was compiling and linking correctly. The workspace was also building the main application and my error was that I had inadvertently included a new (DLL) source file into the build file list of the application itself.
我浪费时间在我的 DLL 中寻找正确编译和链接的问题。工作区也在构建主应用程序，我的错误是我无意中将一个新的 (DLL) 源文件包含到应用程序本身的构建文件列表中。
The main program requires the DLL header mynewdll.h to import things but does not require the source file mynewdll.cpp. (The code is brought in at run time with a DLL.) I have a habit of including header and code files into projects as a pair, and this is where I had gone wrong.
主程序需要 DLL 头文件 mynewdll.h 来导入东西，但不需要源文件 mynewdll.cpp。（代码是在运行时通过 DLL 引入的。）我习惯于将头文件和代码文件成对包含在项目中，这就是我出错的地方。
I would have detected the error much sooner if I had been alert and noticed that the DLL project linked with no errors and it was the main program that complained!
如果我保持警惕并注意到 DLL 项目链接时没有错误，并且抱怨的是主程序，我会更早地检测到错误！
My DLL source code and project was error free and it was only the way I tried to build my executable that was faulty.
我的 DLL 源代码和项目没有错误，这只是我尝试构建可执行文件的方式有问题。
回答by peter karasev
[ CMake inconsistent dll linkage ]
[CMake 不一致的 dll 链接]
I encountered the following issue + solution with the __declspec(dllexport) + __declspec(dllimport) :
我在 __declspec(dllexport) + __declspec(dllimport) 中遇到了以下问题 + 解决方案：
# # #CMakeLists.txt
add_defintions(-DMYLIB=1)
# The above was the solution...
# (MYLIB is used in the standard ifdef + define MYLIB_EXPORT syntax)
# Below: seems to get overruled by other directory's headers:
set_source_files_properties( file1.h file2.h COMPILE_FLAGS "-DMYLIB=1")
This was annoying because a number of sources say to use the 'set source file properties' command to get better granularity but the doc is not clear on what happens to file1.h's declares when included from a different directory... better stick with add_definitions( -DMYLIB=1 )for now!
这很烦人，因为许多消息来源说使用“设置源文件属性”命令来获得更好的粒度，但文档不清楚当包含在不同目录中时 file1.h 的声明会发生什么……最好坚持add_definitions( -DMYLIB=1 )for现在！
To catch this problem: in your Foo.cpp file:
要解决这个问题：在你的 Foo.cpp 文件中：
#include "export.h"
#if defined(MYLIB)
#if defined(OTHERLIB)
static_assert(0,"error, check your definitions!");
// OTHER depends on MY; can't have both of these flags being set!
#endif
#endif
struct OTHER_EXPORT foo
{
};
回答by StndFish
In my case, error C4273 was caused by trying linking to .lib file from a DLL dynamic load tester app in Qt5 by msvc2017_64 toolchain. Removing the reference to .lib file by changing LIBS setting in .pro file have the problem solved.
就我而言，错误 C4273 是由于尝试通过 msvc2017_64 工具链从 Qt5 中的 DLL 动态负载测试器应用程序链接到 .lib 文件引起的。通过更改 .pro 文件中的 LIBS 设置来删除对 .lib 文件的引用已解决问题。
回答by damian
See that you are not defining the exported symbols in a different project. Also clean all the intermediate files by hand and recompile.
请注意您没有在不同的项目中定义导出的符号。还要手动清理所有中间文件并重新编译。
