Я получаю эту ошибку компоновщика.
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, компоновщик жалуется, что есть два DllMain, один в нашем коде, один в Dllmodule.obj.
Поэтому нам нужно указать компоновщику добавить наш dllmain.obj для __afxForceUSRDLL. Поэтому нам нужно определить __afxForceUSRDLL в нашем собственном файле cpp, где определен наш собственный DllMain, тогда компоновщик проигнорирует dllmodule.obj mfc и увидит только один DllMain и никогда не будет жаловаться.
//AFX_MANAGE_STATE(AfxGetStaticModuleState()); stackoverflow.com/a/9070135/1641556
- person Elshan; 19.04.2016
Если вы определяете свой собственный DllMain, в настройках проекта вам необходимо установить «Использование MFC» в «Свойства конфигурации / Общие» на «Использовать стандартные библиотеки Windows».
Вы должны выполнить чистую перестройку после его изменения.
В моем проекте мне удалось решить эту проблему, добавив mfcs80.lib и msvcrt.lib в качестве дополнительных зависимостей в настройках проекта. «Дополнительные зависимости» можно найти в Linker -> Input.
В конфигурации отладки это должны быть mfcs80d.lib и msvcrtd.lib соответственно.
Кстати, я работаю с Visual Studio 2010, поэтому в моем случае библиотека MFC называется 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 C ++ компилирует исходные файлы в алфавитном порядке и передает скомпилированные объектные файлы компоновщику в алфавитном порядке. Если компоновщик сначала обрабатывает DLLDATAX.OBJ, исходный код ссылается на DllMain, который компоновщик загружает из MSVCRTD.LIB (dllmain.obj). Затем компоновщик обрабатывает объектный файл, скомпилированный из файла C ++, который содержит #include «stdafx.h», который ссылается на символ __afxForceUSRDLL, который компоновщик загружает из MFC42D.LIB (dllmodul.obj). Этот объектный модуль также содержит реализацию DllMain, вызывающую конфликт.
У меня очень похожая проблема. [mfcs110d.lib (dllmodul.obj): ошибка LNK2005: _DllMain @ 12 уже определена в MSVCRTD.lib (dllmain.obj)], и решением было добавить mfcs110d.lib в Дополнительные зависимости
Для всех, кто сталкивается с этой ошибкой в проектах ATL (в основном при попытке добавить поддержку MFC), вот решение, которое я нашел после нескольких дней разочарований!
Прежде всего, эта ссылка была для меня более полезной, чем все остальные. Это указывало мне на правильное направление. Проблема возникает, если «сгенерированные файлы» (содержащие код прокси и заглушки, как и идентификаторы типов) по какой-то причине были удалены и прочитаны в проект. Это заставляет Visual Studio добавлять их в неправильном порядке!
Обычно вы сначала сталкиваетесь с ошибкой «ATL требует компиляции C ++», но вы могли исправить это, отключив параметр 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Исправив порядок сборки, мой проект был исправлен, и я смог создать новую чистую сборку.
Я лично избавился от этой ошибки следующим образом: щелкнул правой кнопкой мыши проект в Solution Explorer, выбрал Properties во всплывающем меню, щелкнул вкладку Linker и добавил mfcs71ud.lib в Additional Dependencies. Если вы используете Visual Studio 2005, оно должно быть «80» вместо «71» и так далее.
В моем случае у меня возникла проблема с директивами препроцессора. По какой-то причине _USRDLL был определен, хотя этого не должно было быть.
Чтобы проверить это, перейдите в меню Project, выберите Project Properties, затем выберите фрагмент Configuration Properties -> Preprocessor .
Здесь вы найдете директивы препроцессора.
Просто #undef _USRDLL перед включением afx.h или, что еще лучше, отредактируйте конфигурацию проекта и удалите макрос.
Это обычная конфигурация библиотеки DLL расширения MFC: Параметры сборки для библиотеки DLL MFC
Убедитесь, что вы включили «Stdafx.h» в начало каждого файла .cpp. Я получал ту же ошибку, и у меня был единственный файл .cpp, который вообще не включал этот заголовок. Добавление #include решило проблему.
Я нашел решение здесь Порядок связывания библиотеки Visual Studio 2010
это: / FORCE: MULTIPLE в параметрах компоновщика
Мне пришлось смешать ATL и MFC вместе, чтобы использовать [module (name = "mymodule")]; конструкция в приложении MFC вместе с ключевым словом "__hook"
Я обнаружил, что это мне помогло: http://support.microsoft.com/kb/148652
В основном порядок компоновщика был неправильным. библиотеки CRT связывались раньше, чем библиотеки MFC. Оказывается, библиотеки MFC нужно было связать СНАЧАЛА, а затем можно было связать библиотеки CRT.
Юко, Microsoft !!
Объявите mfc80ud.lib и mfcs80ud.lib в поле Additional Dependancies в Project Properties -> Linker Tab -> Input of Visual Studio, чтобы исправить проблему.
Здесь есть общая тема, проходящая через некоторые ответы.
Авишек Бозе: -
Объявите 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 в Дополнительные зависимости
Таким образом, в общем случае кажется, что сначала нужно найти имя добавляемой библиотеки ...
а потом добавить ....
Обратите внимание, что, похоже, есть некоторые предварительные требования и / или альтернативные решения.
Это также может произойти, если в вашем решении несколько проектов, экспортирующих одни и те же символы. Например, если у вас есть подпроект, который строит foo.dll с файлом foo.def, который экспортирует DoFoo и подпроект для bar.dll с файлом bar.def, который экспортирует DoFoo, произойдет коллизия, и это будет ошибку вы увидите при ссылке.
