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

23

Я получаю эту ошибку компоновщика.

mfcs80.lib(dllmodul.obj): ошибка LNK2005: _DllMain @12, уже определенная в MSVCRT.lib(dllmain.obj)

Скажите, пожалуйста, правильный способ устранения этой ошибки. Я прочитал решение на сайте поддержки microsoft об этой ошибке, но это не помогло.

Я использую VS 2005 с Platform SDK

Теги:
linker
visual-c++

15 ответов

14
Лучший ответ

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

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

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

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

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

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

  • узнать, какая из двух библиотек вам действительно нужна
  • узнайте, как рассказать компоновщику не использовать другой (используя, к примеру, отзыв от Джеймса Хопкина).
  • 3
    +1 Хороший вопрос - я не совсем правильно прочитал ошибку. У меня недавно была похожая ошибка компоновщика, когда опция библиотек MFC загадочным образом включилась.
  • 0
    Точное объяснение. Спасибо за это. :)
Показать ещё 1 комментарий
32

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

  • 0
    Работал для меня, у меня был включен AfxWin.h и немного другая библиотека, вызывающая проблему: uafxcwd.lib (dllmodul.obj): ошибка LNK2005: _DllMain @12 12 уже определена
  • 0
    работал для меня, я использую VS2010.
Показать ещё 7 комментариев
9

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

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

  • 3
    У меня есть чистая C, не MFC DLL, установленная на «Использовать стандартные библиотеки Windows», но ошибка все еще появляется.
  • 0
    Я тоже. VS2010.
Показать ещё 1 комментарий
6

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

  • 1
    У меня было наоборот! У меня был мошенник _USRDLL в препроцессоре, который должен был быть _LIB. Doh!
6

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

  • 0
    Ссылка, которую вы предложили, помогла мне найти решение. Стоит прочитать.
3

Для всех тех, кто испытывает эту ошибку в проектах ATL (в основном при попытке добавить поддержку MFC), вот решение, которое я нашел после нескольких дней разочарования!

Прежде всего, эта ссылка была для меня более полезной, чем все остальные. Он указал мне в правильном направлении. Проблема возникает, если по какой-то причине "сгенерированные файлы" (содержащие прокси-сервер и код-заглушки, так же как и типы) были удалены и прочитаны в проекте. Это заставляет Visual Studio добавлять их в неправильном порядке!

Обычно вы сначала сталкиваетесь с ошибкой "ATL требует компиляции С++", но вы можете исправить это, отключив параметр Yc/Yu (предварительно скомпилированные заголовки) для этого файла.

Что вы должны сделать дальше, это разгрузить проект и отредактировать его. Найдите группы товаров, которые определяют порядок сборки и включают порядок (ClCompile и ClInclude). Проверьте их порядок и настройки.

Компиляторы должны отображаться в следующем порядке:

  • dllmain.cppCompileAsManaged установлено значение false и PrecompiledHeader осталось пустым).
  • Источник библиотеки (MyLib.cpp, содержащий DllCanUnloadNow и т.д.)
  • Код прокси-сервера (MyLib_i.c; с теми же настройками, что и dllmain.cpp)
  • stdafx.cppPrecompiledHeader установлено значение Create)
  • Все остальные исходные файлы библиотеки (фактическое содержимое библиотек)
  • xdlldata.c (с теми же настройками, что и dllmain.cpp)

Затем заказы должны быть упорядочены следующим образом:

  • dllmain.h
  • MyLib_i.h
  • Resource.h
  • stdafx.h
  • targetver.h
  • ... (фактические заголовки библиотек)
  • xdlldata.h

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

  • 1
    Просто хотел прокомментировать, что этот ответ был чрезвычайно полезен; Я не знал, что компоновщик зависел от порядка включения компоновки в проекте, но на самом деле это решило проблему для меня.
3

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

2

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

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

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

  • 0
    Этот совет должен быть слегка обновлен для Visual Studio 2107. Выберите проект в обозревателе решений, щелкните правой кнопкой мыши и выберите «Свойства». Теперь перейдите в C / C ++> Препроцессор> Определения препроцессора и отредактируйте _USRDLL
1

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

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

1

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

1

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

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

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

0

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

  • 0
    Хотя кто-то и дал тот же ответ около года назад, он стоит на вершине, поэтому я оставлю здесь свои 5 центов. Кажется, msvcrt.dll импортирует dllmain только тогда, когда это не было объявлено ранее. Добавление файла mfc * .dll к «Дополнительные зависимости» делает его обработкой раньше и решает проблему. Как кто-то еще упомянул / FORCE: MULTIPLE также ускользает от компоновщика, но в моем случае произвёл .dll сбой во время выполнения.
0

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

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

Yucko Microsoft!!

0

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

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню