Использование отладочных / выпускных версий DLL в C ++ - PullRequest
1 голос
/ 10 октября 2010

Я пишу приложение на C ++, которое можно скомпилировать под Linux (gcc 4.3) и Windows (MS VS08 Express).

Мое приложение использует сторонние библиотеки,

В Linux они скомпилированы как общие библиотеки, а на Windows есть две версии «Отладка» и «Выпуск».

Я знаю, что debug версия предоставляет дополнительную поддержку для отладки (точно так же, как использование опции -ggdb в linux gcc, верно?)

Но я обнаружил, что если мое приложение находится в версии debug , библиотеки также должны быть в версии debug , в противном случае приложение завершится сбоем.

Почему существует такой предел? Кажется, что в мире Linux нет таких ограничений

Большое спасибо!

Ответы [ 3 ]

5 голосов
/ 10 октября 2010

Скорее всего, версии Release и Debug связаны с различными версиями библиотеки времени выполнения C ++. Обычно сборка Debug ссылается на среду выполнения «Многопоточная отладочная DLL», тогда как сборка выпуска обычно связывается с «Многопоточная библиотека DLL». Загрузка DLL, библиотеки времени выполнения которых не совпадают с библиотеками приложения, часто приводит к таинственным сбоям.

Вы можете попытаться проверить, что все ваши библиотеки DLL собраны на основе той же библиотеки времени выполнения, что и ваше приложение, независимо от того, какая конфигурация (Debug или Release) активна. Желательно это или нет - это совсем другой вопрос.

Возможность выбрать, с какой библиотекой времени выполнения связать библиотеку, позволяет разработчику приложения выбирать лучший набор функций с учетом требований ее приложения. Например, однопоточное приложение может понести потери производительности из-за ненужной синхронизации потоков, если оно связано с библиотекой времени выполнения, разработанной с учетом безопасности потоков. Аналогично, последствия связывания многопоточного приложения с однопоточным временем выполнения могут быть катастрофическими.

5 голосов
/ 10 октября 2010

Конфигурация отладки вашего Программа составлена ​​с полной символикой отладочная информация и без оптимизации. Оптимизация усложняет отладку, потому что отношения между исходный код и сгенерированные инструкции более сложный.

Конфигурация выпуска вашего программа не содержит символической отладки информация и полностью оптимизирована. Отладочная информация может быть сгенерирована в Файлы PDB (C ++) в зависимости от используемые параметры компилятора. Создание PDB файлы могут быть очень полезны, если вы позже необходимо отладить релизную версию.

Отладка против выпуска

Также возможно отладить вашу сборку релиза с помощью флагов компилятора.

Отладка сборок релиза

  • Расположение кучи - защитные байты для предотвращения перезаписи
  • Компиляция - удаление Assert / Debug Info
  • Поддержка указателей - буфер вокруг указателей для предотвращения ошибок сегментов
  • Оптимизация - встроенные функции

Распространенные проблемы при создании сборок релиза

Чтобы уточнить Мартина Торнуолла. Различные библиотеки, связанные в Debug или Release

  • LIBCPMT.LIB, Многопоточная, статическая связь, / MT, _MT

  • LIBCPMTD.LIB, Многопоточная, статическая ссылка, / MTd, _DEBUG, _MT

Библиотеки CRT

2 голосов
/ 10 октября 2010

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

Они поддерживают функцию, называемую «отладка итератора», которая по умолчанию включена в конфигурации отладки.Это добавляет членов к классам, чтобы помочь диагностический код.Делая их больше.Это плохо, когда вы создаете объект в куске кода, который был скомпилирован с одним параметром, и передаете его в код, который был скомпилирован с противоположным параметром.Вы можете отключить это, установив для макроса _HAS_ITERATOR_DEBUGGING значение 0. Это довольно большая потеря, эта функция отлично подходит для диагностики ошибок при использовании классов STL.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...