О непоследовательной связи DLL

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

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': inconsisten t dll link

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

#ifdef _GUICTRLS
   #define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
   #define GUI_CTRLS_EXPORT  __declspec(dllimport)
#endif
34
07 апр. '10 в 15:51
источник поделиться
6 ответов

Существует несколько возможностей:

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

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

см

Как использовать _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) Вероятно, у вас есть дублированное определение/декларация.

15
14 янв. '11 в 17:32
источник

Назначение инструкций препроцессора:

#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/С++ → Preprocessor → Определения препроцессора.

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

35
12 мая '10 в 23:33
источник

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

2
07 апр. '10 в 16:50
источник

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

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

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

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

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

1
11 мая '15 в 13:11
источник

[CMOS несовместимая связь 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 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 
{ 
};
1
03 сент. '14 в 10:35
источник

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

0
16 марта '13 в 11:29
источник

Посмотрите другие вопросы по меткам или Задайте вопрос