Ошибка LNK2005: _DllMain @12, уже определенная в MSVCRT.lib

Ответ 1

Если вы внимательно прочитали ошибку компоновщика и примените некоторые знания, вы можете попасть туда сами:

Компонент связывает несколько скомпилированных объектов и библиотек вместе, чтобы получить двоичный файл.

Каждый объект/библиотека описывает

• какие символы он ожидает присутствовать в других объектах
• какие символы он определяет

Если два объекта определяют один и тот же символ, вы получаете именно эту ошибку компоновщика. В вашем случае как mfcs80.lib, так и MSVCRT.lib определяют символ _DllMain @12.

Как избавиться от ошибки:

• узнать, какая из двух библиотек вам действительно нужна
• узнайте, как рассказать компоновщику не использовать другой (используя, к примеру, отзыв от Джеймса Хопкина).

Ответ 2

У меня было такое же сообщение об ошибке, но ни один из ответов здесь не разрешил для меня. Поэтому, если вы столкнулись с этой проблемой при создании 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 и никогда не жалуется.

Источник: http://social.msdn.microsoft.com/Forums/en-US/0d78aa6b-1e87-4c01-a4a7-691335b7351a/how-to-build-mfc-application-dll-in-visual-c-2010

Ответ 3

Если вы определяете свой собственный DllMain, в настройках вашего проекта вам нужно установить "Использовать MFC" в "Свойства конфигурации/Общие" для "Использовать стандартные библиотеки Windows".

Вы должны сделать чистую перестройку после ее изменения.

Ответ 4

В моем проекте я смог решить эту проблему, добавив 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, за исключением того, что мне не нужно вводить все в поле "Игнорировать конкретные библиотеки по умолчанию".

Ответ 5

Для меня прямая причина была действительно отсутствующей ссылкой на символ _afxForceUSRDLL, но косвенной причиной было отсутствие определения макроса _USRDLL. Он определяется по умолчанию мастером VC, но иногда разработчики стирают его ошибочно. Вот несколько слов.

Ответ 6

Идентификатор базы знаний 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, вызывая конфликт.

Ответ 7

Для всех тех, кто испытывает эту ошибку в проектах 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.h
• MyLib_i.h
• Resource.h
• stdafx.h
• targetver.h
• ... (фактические заголовки библиотек)
• xdlldata.h

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

Ответ 8

У меня очень похожая проблема. [mfcs110d.lib(dllmodul.obj): ошибка LNK2005: _DllMain @12 уже определена в MSVCRTD.lib(dllmain.obj)], и решение было добавить mfcs110d.lib в дополнительные зависимости

Ответ 9

В моем случае у меня была проблема с директивами препроцессора. По какой-то причине _USRDLL был определен, когда он не должен был быть.

Чтобы проверить это, перейдите в меню Project , выберите Project Properties , затем выберите фрагмент Configuration Properties → Preprocessor .

Здесь будут найдены директивы препроцессора.

Ответ 10

Я лично избавился от этой ошибки следующим образом: проект с правой кнопкой мыши в Solution Explorer, выбранном Properties из всплывающего меню, нажал вкладку Linker и добавил mfcs71ud.lib в Additional Dependencies. Если вы используете Visual Studio 2005, это должно быть "80" вместо "71" и т.д.

Ответ 11

Просто #undef _USRDLL перед включением afx.h или даже лучше отредактируйте конфигурацию проекта и удалите макрос.

Это обычная конфигурация для DLL расширения MFC: Настройки сборки для MFC DLL

Ответ 12

Я нашел решение здесь Порядок компоновки библиотек Visual Studio 2010

это:/FORCE: MULTIPLE в вариантах компоновщика

Мне пришлось смешивать ATL и MFC вместе, чтобы использовать [module (name = "mymodule" )]; в приложении MFC вместе с ключевым словом "__hook"

Ответ 13

Я нашел это, что помогло мне: http://support.microsoft.com/kb/148652

В основном порядок компоновщика был неправильным. CRT libs связывались перед библиотекой MFC. Оказывается, библиотеки MFC должны были быть связаны FIRST, а затем библиотеки CRT могли быть связаны.

Yucko Microsoft!!

Ответ 14

Объявите mfc80ud.lib и mfcs80ud.lib в поле Additional Dependancies в Project Properties -> Linker Tab -> Input of Visual Studio, чтобы устранить проблему.

Ответ 15

Убедитесь, что вы включили "Stdafx.h" в начало каждого файла .cpp. Я получал ту же ошибку и имел единственный .cpp файл, который вообще не включал этот заголовок. Добавление #include решило проблему.

Ответ 16

Здесь есть общая тема, проходящая через некоторые ответы.

Авишек Бозе: -

Объявите 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 в Дополнительные зависимости

Таким образом, в общем случае кажется, что сначала нужно найти имя библиотеки для добавления...

а потом добавить его....

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