Обнаружено несоответствие для '_ITERATOR_DEBUG_LEVEL': значение '0' не соответствует значению '2'

Построение с VS2010, я создаю lib, который вызывает многие из этих ошибок ссылок:

error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2'

Результат в ситуации, когда я должен отправить как выпуск, так и отладочную версию моей библиотеки. У меня нет причин отправлять отладочную версию lib, и она просто раздувает бинарный дистрибутив. Но клиентский код, встроенный в debug, отказывается ссылаться на мою версию lib.

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

Аналогично libs, которые жалуются, когда используются конфликтующие CRT, которые можно предотвратить с помощью /Zl (исключить имя библиотеки по умолчанию из объектных файлов), наверняка есть способ предотвратить эту зависимость от того, чтобы быть включенным в мои библиотеки тоже?

Я просто хочу создать единую оптимизированную библиотеку lib, которая может связываться с кодом отладки или выпуска. Это не важно для клиентского кода для отладки lib. Почти никакие сторонние библиотеки не поставляются с отличными версиями отладки и выпуска. Как разработчики избегают этой проблемы?

Кто-нибудь знает, что именно заставляет эту зависимость ссылок, и как мне ее полностью отключить или исключить из моего кода?

Ответ 1

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

Эта ошибка ссылки мешает вам сдуть вашу ногу так. Ну, обе ноги, левая рука и указательный палец правой руки, вам придется управлять мышью с подбородком. Ошибки времени выполнения, которые вы получаете, например, std::string объектов, имеющих разный макет, очень трудно диагностировать. Кучное повреждение - неприятная проблема, о худшем - отладка. Вы должны перекомпилировать код с одинаковыми настройками, иначе нет.

Ответ 2

Такая же проблема, но я писал регрессионные тесты и компиляцию командной строки сценариев и ссылку. Я просто забыл /D _DEBUG на линии компиляции при выполнении отладочной сборки.

Ответ 3

Замените 0 на 2 в файлах lib, участвующих в компиляции.

Ответ 4

Вы можете попытаться определить _ITERATOR_DEBUG_LEVEL как 0 в настройках проекта для конфигурации отладки или...

Чтобы указать значение для макроса _ITERATOR_DEBUG_LEVEL, используйте параметр /D компилятор, чтобы определить его в командной строке или использовать #define до того, как заголовки стандартной библиотеки С++ будут включены в ваш источник файлы. Например, в командной строке для компиляции sample.cpp в debug mode и использовать поддержку итератора отладки, вы можете указать Определение макроса _ITERATOR_DEBUG_LEVEL:

cl /EHsc /Zi /MDd /D_ITERATOR_DEBUG_LEVEL=0 sample.cpp

В исходном файле укажите макрос перед любой стандартной библиотекой заголовки, определяющие итераторы.

C++

// sample.cpp  

#define _ITERATOR_DEBUG_LEVEL 0

#include <vector>  

// ...