Ошибки компоновщика при компиляции DLL в конфигурации отладки со статической компоновкой в ​​MSVC ++ 2010 - PullRequest
0 голосов
/ 16 августа 2011

Я бы хотел использовать опцию компоновщика / MTd вместо / MDd для отладочной сборки моего проекта DLL.Я использую статическое связывание для сборок Release.В конфигурации отладки я получаю ошибки компоновщика:

break.obj : error LNK2005: 
"public: void __thiscall std::_Container_base12::_Orphan_all(void)"
(?_Orphan_all@_Container_base12@std@@QAEXXZ)
is already defined in msvcprtd.lib(MSVCP100D.dll).

В общей сложности 5 подобных ошибок, все LNK2005 в break.obj, все упоминающие эту вещь base12.break.obj - это файл в алфавитном порядке, поэтому, возможно, проблема возникнет и с другими файлами.Я не определяю функции с этим именем в этом файле.Что там происходит?

1 Ответ

2 голосов
/ 16 августа 2011

Может быть, опубликовать некоторые из журнала сборки - что-то вызывает выполнение среды DLL в шаге ссылки.

Убедитесь, что вы все очистили и выполнили полное восстановление. Если это не помогло, убедитесь, что для одного или нескольких исходных файлов отсутствуют параметры проекта на уровне файлов, что может привести к его перестройке для связи со средой выполнения DLL. Насколько я знаю, нет простого способа идентифицировать такие переопределения на уровне файлов из IDE. Просмотр журналов сборки или файла .vcxproj непосредственно в текстовом редакторе может помочь сузить это. Если вы посмотрите в файл .vcxproj, исходный файл с переопределениями проекта будет иметь элементы XML для переопределенных настроек в элементе <ClCompile> файла, где большинство элементов <ClCompile> не будут иметь подэлементов.

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


В качестве дополнительного примечания MSDN сообщает (http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx):

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

Кстати, _Container_base12 - это тип, используемый для проверки / отладки итератора, поэтому вы не видите его или каких-либо его функций-членов напрямую ни в одном из ваших исходных файлов. Убедитесь, что вы ничего не делаете неправильно с настройками макроса _HAS_ITERATOR_DEBUGGING и _SECURE_SCL. Но я не думаю, что это как-то связано с вашей конкретной конкретной проблемой. Если вы в конечном итоге подумали, что они связаны с вашей проблемой, вы можете проверить:

...