Я получаю эту ошибку компоновщика.
mfcs80.lib(dllmodul.obj): ошибка LNK2005: _DllMain @12, уже определенная в MSVCRT.lib(dllmain.obj)
Скажите, пожалуйста, правильный способ устранения этой ошибки. Я прочитал решение на сайте поддержки microsoft об этой ошибке, но это не помогло.
Я использую VS 2005 с Platform SDK
Если вы внимательно прочитали ошибку компоновщика и примените некоторые знания, вы можете попасть туда сами:
Компонент связывает несколько скомпилированных объектов и библиотек вместе, чтобы получить двоичный файл.
Каждый объект/библиотека описывает
Если два объекта определяют один и тот же символ, вы получаете именно эту ошибку компоновщика. В вашем случае как mfcs80.lib, так и MSVCRT.lib определяют символ _DllMain @12.
Как избавиться от ошибки:
У меня было такое же сообщение об ошибке, но ни один из ответов здесь не разрешил для меня. Поэтому, если вы столкнулись с этой проблемой при создании DLL-проекта, который использует MFC, его можно решить, введя следующую строку:
extern "C" { int _afxForceUSRDLL; }
в файл cpp, где DllMain определен. Затем используется ваша собственная реализация DllMain, а не одна из dllmain.obj.
Когда мы пытаемся использовать библиотеку MFC, мы обязательно включим afx.h напрямую или косвенно, то MFC (afx.h) сообщает компоновщику, чтобы найти символ __afxForceUSRDLL и поместите этот объект, который содержит __afxForceUSRDLL в программу, поэтому линкер выполняет поиск и помещает dllmodule.obj в наш потому что __afxForceUSRDLL определяется в dllmodule.cpp.
Это общий сценарий. Когда мы хотим использовать наш собственный DllMain в mfc dll project, компоновщик жалуется, что есть два DllMain, один в наш код, один в Dllmodule.obj.
Итак, нам нужно сказать компоновщику, чтобы добавить наш dllmain.obj для __afxForceUSRDLL. Поэтому нам нужно определить __afxForceUSRDLL в нашем собственном файле cpp, где определен наш собственный DllMain, тогда компоновщик будет игнорировать mfcs dllmodule.obj и видеть только один DllMain и никогда не жалуется.
Если вы определяете свой собственный DllMain, в настройках вашего проекта вам нужно установить "Использовать MFC" в "Свойства конфигурации/Общие" для "Использовать стандартные библиотеки Windows".
Вы должны сделать чистую перестройку после ее изменения.
В моем проекте я смог решить эту проблему, добавив mfcs80.lib и msvcrt.lib в качестве дополнительных зависимостей в настройках проекта. "Дополнительные зависимости" можно найти в Linker → Input.
В конфигурации отладки, которая должна быть mfcs80d.lib и msvcrtd.lib соответственно.
Кстати, я работаю с Visual Studio 2010, поэтому в моем случае MFC lib называется mfc100.lib.
Я не уверен, почему это сработало. Нет необходимости добавлять эти файлы lib в качестве дополнительных зависимостей, потому что я уже установил "Использование MFC" в "Использовать MFC в общей DLL". Я предполагаю, что, указав эти библиотеки в качестве дополнительных зависимостей, они связаны в другом порядке.
Это решение более или менее совпадает с тем, которое предлагается на сайте Microsoft: http://support.microsoft.com/kb/148652, за исключением того, что мне не нужно вводить все в поле "Игнорировать конкретные библиотеки по умолчанию".
Для меня прямая причина была действительно отсутствующей ссылкой на символ _afxForceUSRDLL, но косвенной причиной было отсутствие определения макроса _USRDLL. Он определяется по умолчанию мастером VC, но иногда разработчики стирают его ошибочно. Вот несколько слов.
Идентификатор базы знаний MSDN Q148652.
http://support.microsoft.com/kb/148652
Причина: Visual С++ компилирует исходные файлы в алфавитном порядке и передает скомпилированные объектные файлы в компоновщик в алфавитном порядке. Если компоновщик сначала обрабатывает DLLDATAX.OBJ, исходный код ссылается на DllMain, который компоновщик загружает из MSVCRTD.LIB(dllmain.obj). Затем компоновщик обрабатывает объектный файл, скомпилированный из файла С++, который содержит #include "stdafx.h", который ссылается на символ __afxForceUSRDLL, который компоновщик загружает из MFC42D.LIB(dllmodul.obj). Этот объектный модуль также содержит реализацию для DllMain, вызывая конфликт.
Для всех тех, кто испытывает эту ошибку в проектах ATL (в основном при попытке добавить поддержку MFC), вот решение, которое я нашел после нескольких дней разочарования!
Прежде всего, эта ссылка была для меня более полезной, чем все остальные. Он указал мне в правильном направлении. Проблема возникает, если по какой-то причине "сгенерированные файлы" (содержащие прокси-сервер и код-заглушки, так же как и типы) были удалены и прочитаны в проекте. Это заставляет Visual Studio добавлять их в неправильном порядке!
Обычно вы сначала сталкиваетесь с ошибкой "ATL требует компиляции С++", но вы можете исправить это, отключив параметр Yc/Yu (предварительно скомпилированные заголовки) для этого файла.
Что вы должны сделать дальше, это разгрузить проект и отредактировать его. Найдите группы товаров, которые определяют порядок сборки и включают порядок (ClCompile и ClInclude). Проверьте их порядок и настройки.
Компиляторы должны отображаться в следующем порядке:
dllmain.cpp (с CompileAsManaged установлено значение false и PrecompiledHeader осталось пустым).MyLib.cpp, содержащий DllCanUnloadNow и т.д.)MyLib_i.c; с теми же настройками, что и dllmain.cpp)stdafx.cpp (с PrecompiledHeader установлено значение Create)xdlldata.c (с теми же настройками, что и dllmain.cpp)Затем заказы должны быть упорядочены следующим образом:
dllmain.hMyLib_i.hResource.hstdafx.htargetver.hxdlldata.hФиксирование порядка сборки зафиксировал мой проект, и я смог создать новую чистую сборку.
У меня очень похожая проблема. [mfcs110d.lib(dllmodul.obj): ошибка LNK2005: _DllMain @12 уже определена в MSVCRTD.lib(dllmain.obj)], и решение было добавить mfcs110d.lib в дополнительные зависимости
В моем случае у меня была проблема с директивами препроцессора.
По какой-то причине _USRDLL был определен, когда он не должен был быть.
Чтобы проверить это, перейдите в меню Project , выберите Project Properties , затем выберите фрагмент Configuration Properties → Preprocessor .
Здесь будут найдены директивы препроцессора.
Я лично избавился от этой ошибки следующим образом: проект с правой кнопкой мыши в Solution Explorer, выбранном Properties из всплывающего меню, нажал вкладку Linker и добавил mfcs71ud.lib в Additional Dependencies. Если вы используете Visual Studio 2005, это должно быть "80" вместо "71" и т.д.
Просто #undef _USRDLL перед включением afx.h или даже лучше отредактируйте конфигурацию проекта и удалите макрос.
Это обычная конфигурация для DLL расширения MFC: Настройки сборки для MFC DLL
Я нашел решение здесь Порядок компоновки библиотек Visual Studio 2010
это:/FORCE: MULTIPLE в вариантах компоновщика
Мне пришлось смешивать ATL и MFC вместе, чтобы использовать [module (name = "mymodule" )]; в приложении MFC вместе с ключевым словом "__hook"
Я нашел это, что помогло мне: http://support.microsoft.com/kb/148652
В основном порядок компоновщика был неправильным. CRT libs связывались перед библиотекой MFC. Оказывается, библиотеки MFC должны были быть связаны FIRST, а затем библиотеки CRT могли быть связаны.
Yucko Microsoft!!
Объявите mfc80ud.lib и mfcs80ud.lib в поле Additional Dependancies в Project Properties -> Linker Tab -> Input of Visual Studio, чтобы устранить проблему.
Убедитесь, что вы включили "Stdafx.h" в начало каждого файла .cpp. Я получал ту же ошибку и имел единственный .cpp файл, который вообще не включал этот заголовок. Добавление #include решило проблему.
Здесь есть общая тема, проходящая через некоторые ответы.
Авишек Бозе: -
Объявите mfc80ud.lib и mfcs80ud.lib в поле "Дополнительные зависимости" в "Свойства проекта" → "Вкладка компоновщика" → ввод Visual Studio, чтобы устранить проблему.
vmb100: -
Я работаю с Visual Studio 2010, поэтому в моем случае библиотека MFC называется mfc100.lib.
joseAndresGomezTovar: -
У меня очень похожая проблема. [mfcs110d.lib(dllmodul.obj): ошибка LNK2005: _DllMain @12 уже определена в MSVCRTD.lib(dllmain.obj)], и было решено добавить mfcs110d.lib в Дополнительные зависимости
Таким образом, в общем случае кажется, что сначала нужно найти имя библиотеки для добавления...
а потом добавить его....
Обратите внимание, что, похоже, существуют некоторые предпосылки и/или альтернативные решения.