Inconsistent dll linkage ошибка

asked Apr 7, 2010 at 12:51

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.

answered May 12, 2010 at 20:33

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.

answered May 11, 2015 at 10:11

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?

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

answered Sep 3, 2014 at 7:35

answered Mar 16, 2013 at 8:29

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.

answered May 8, 2022 at 8:19

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.