关于不一致的dll联动

Question

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': inconsistent dll linkage

I have also export and import definitions, like:

#ifdef _GUICTRLS
   #define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
   #define GUI_CTRLS_EXPORT  __declspec(dllimport)
#endif

Answer 1

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.

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.

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.

Answer 2

There are multiple possibilities:

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

see:

How To Use _declspec(dllexport) in an MFC Extension DLL: http://support.microsoft.com/kb/128199

AFX_EXTENSION_MODULE Structure: http://msdn.microsoft.com/en-us/library/sxfyk0zk.aspx

TN033: DLL Version of MFC: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx

2) It is likely that you have a duplicated definiton/declaration.

Answer 3

In addition to reading the warning message, pay attention to where it occurs if 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 .

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.

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!

My DLL source code and project was error free and it was only the way I tried to build my executable that was faulty.

Answer 4

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?

Answer 5

[ CMake inconsistent dll linkage ]

I encountered the following issue + solution with the __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!

To catch this problem: in your Foo.cpp file:

#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 
{ 
};

Answer 6

See that you are not defining the exported symbols in a different project. Also clean all the intermediate files by hand and recompile.

Answer 7

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.

Answer 8

Just by changing the order of my headers, the warning has been removed. I've only moved first the header containing the __declspec(dllexport).

I've also looked if there's some duplication but find none.

I'm asking myself why this works....

Answer 9

To elaborate the answer of damian with an example. I read it but didn't understand at first glance.

You have a shared library with a source file compiled in that contains the function. In a new project you use the library and in addition you compile also the source file to use the function (I forgot that it is already in the library). Within the library the functions label is exported, within the additional compiled source file the functions label is marked to be imported. That's the conflict.