ошибка LNK2005: _DllMain @ 12 уже определено в MSVCRT.lib - PullRequest
31 голосов
/ 05 декабря 2008

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

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

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

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

Ответы [ 16 ]

41 голосов
/ 12 ноября 2013

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

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

13 голосов
/ 05 декабря 2008

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

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

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

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

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

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

  1. выясните, какая из двух библиотек вам действительно нужна
  2. узнайте, как запретить компоновщику использовать другой (например, совет от James Hopkin )
11 голосов
/ 05 декабря 2008

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

Вы должны сделать чистое восстановление после его изменения.

8 голосов
/ 05 июля 2012

В моем проекте мне удалось решить эту проблему, добавив mfcs80.lib и msvcrt.lib в качестве дополнительных зависимостей в настройках проекта. «Дополнительные зависимости» можно найти в Linker -> Input.

В конфигурации отладки это должны быть mfcs80d.lib и msvcrtd.lib соответственно.

Кстати, я работаю с Visual Studio 2010, поэтому в моем случае библиотека MFC называется mfc100.lib.

Я не уверен, почему это сработало. Нет необходимости добавлять эти файлы lib в качестве дополнительных зависимостей, потому что я уже установил «Use MFC» на «Use MFC in shared dll». Я предполагаю, что, указав эти библиотеки в качестве дополнительных зависимостей, они будут связаны в другом порядке.

Это решение более или менее совпадает с предложенным на сайте Microsoft: http://support.microsoft.com/kb/148652,, за исключением того, что мне не нужно ничего вводить в поле «Игнорировать определенные библиотеки по умолчанию».

6 голосов
/ 06 мая 2015

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

3 голосов
/ 13 января 2015

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

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

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

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

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

  1. dllmain.cppCompileAsManaged, установленным на false и PrecompiledHeader, оставленным пустым).
  2. Исходный код библиотеки (MyLib.cpp, содержащий DllCanUnloadNow и т. Д.)
  3. Код прокси / заглушки (MyLib_i.c; с теми же настройками, что и dllmain.cpp)
  4. stdafx.cppPrecompiledHeader, установленным на Create)
  5. Все остальные исходные файлы библиотеки (ваш фактический контент библиотеки)
  6. xdlldata.c (с теми же настройками, что и dllmain.cpp)

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

  1. dllmain.h
  2. MyLib_i.h
  3. Resource.h
  4. stdafx.h
  5. targetver.h
  6. ... (фактические заголовки библиотеки)
  7. xdlldata.h

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

3 голосов
/ 06 сентября 2013

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

2 голосов
/ 19 августа 2014

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

Для проверки перейдите в меню Проект , выберите Свойства проекта , затем выберите фрагмент Свойства конфигурации -> Препроцессор .

Там находятся директивы препроцессора.

2 голосов
/ 24 апреля 2014

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

1 голос
/ 10 июня 2016

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

...