О противоречивой связи dll - PullRequest
38 голосов
/ 07 апреля 2010

Как я могу удалить эту ссылку предупреждение? Вы видите сегмент кода, который вызывает это предупреждение.

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
    }

предупреждение C4273: 'InitGuiCtrlsDLL': несоответствие связь т * д

У меня также есть определения экспорта и импорта, например:

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

Ответы [ 6 ]

39 голосов
/ 13 мая 2010

Назначение операторов препроцессора:

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

должен убедиться, что заголовочный файл объявляет класс или функцию как __declspec (dllexport) в .dll, где он определен, и как __declspec (dllimport) для любых других .dll, которые могут захотеть его использовать. *

Чтобы это работало, _GUICTRLS должен быть определен при компиляции экспортируемого .dll, а не определен для любых других .dll. Обычно вы ожидаете, что _GUICTRLS будет определен в свойствах проекта в C / C ++ -> Preprocessor -> Preprocessor Definitions.

Ошибка компилятора, которую вы видите, обычно возникает из-за того, что _GUICTRLS не определен для проекта, выполняющего экспорт, или определен для нескольких проектов, как правило, в результате вырезания вставки из одного проекта в другой. Вы также увидите это, если _GUICTRLS определен в заголовочном файле, который включен в несколько проектов.

21 голосов
/ 14 января 2011

Есть несколько возможностей:

1) static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };

Вы используете AFX_EXTENSION_MODULE. Это означает, что вы реализуете расширение MFC DLL. Для таких расширений dll необходимо определить препроцессор _AFXEXT. Установите это в настройках компилятора C ++ вашего проекта Visual C ++

см

Как использовать _declspec (dllexport) в DLL-библиотеке расширения MFC: http://support.microsoft.com/kb/128199

(В настоящее время я не могу опубликовать более 1 ссылки, поскольку моя репутация ниже 10. Я добавлю еще 2 важные ссылки позже. Поэтому, если это решение, пометьте его как ответ, чтобы ускорить процесс;))

Как и было обещано, вот две ссылки:

AFX_EXTENSION_MODULE Структура: http://msdn.microsoft.com/en-us/library/sxfyk0zk.aspx

TN033: версия DLL MFC: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx

2) Вероятно, у вас есть дублированное определение / объявление.

2 голосов
/ 07 апреля 2010

Это предупреждение обычно вызывается дублирующим определением функции с различным использованием dllimport.Вы уверены, что не сделали этого?

1 голос
/ 11 мая 2015

Помимо чтения предупреждающего сообщения, обратите внимание на то, где оно происходит , если у вас есть несколько проектов в составе рабочего пространства.

Я потратил время на поиск проблемы в моей DLL, которая правильно компилировалась и компоновалась. Рабочая область также создавала основное приложение, и моя ошибка заключалась в том, что я случайно включил новый (DLL) исходный файл в список файлов сборки самого приложения .

Основная программа требует DLL-заголовок mynewdll.h для импорта, но не требует исходного файла mynewdll.cpp. (Код вводится во время выполнения с помощью DLL.) У меня есть привычка включать заголовочные файлы и файлы кода в проекты в виде пары, и именно здесь я ошибся.

Я бы обнаружил ошибку намного раньше, если бы был предупрежден и заметил, что проект DLL связан с ошибками, и это была основная программа, которая жаловалась!

Мой исходный код и проект DLL были безошибочны, и это был только способ, которым я пытался построить свой исполняемый файл, который был неисправен.

1 голос
/ 03 сентября 2014

[CMake несовместимая связь dll]

Я столкнулся со следующей проблемой + решение с __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") 

Это раздражало, потому что многие источники говорят, что используют команду «установить свойства исходного файла», чтобы получить лучшую гранулярность, но в документе неясно, что происходит с объявлением file1.h при включении из другого каталога ... лучше придерживайтесь add_definitions( -DMYLIB=1 ) сейчас!

Чтобы уловить эту проблему: в вашем файле 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 
{ 
};
0 голосов
/ 16 марта 2013

Убедитесь, что вы не определяете экспортируемые символы в другом проекте. Также очистите все промежуточные файлы вручную и перекомпилируйте.

...