About inconsistent dll linkage

问题:

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

I have also export and import definitions, like:

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

回答1:

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

(Currently I cannot post more than 1 link because my reputation is less than 10. I will add 2 more important links later. So if this is the solution, mark it as answer to speed-up the process ;) )

As promised, here are the two links:

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.

回答2:

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.

回答3:

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?

回答4:

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

回答5:

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.

回答6:

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