Is/nodefaultlib: msvcr100 правильный подход к обработке msvcr100.dll vs msvcr100d.dll defaultlib issue

Question

Для кросс-платформенного программного проекта, который построен на Linux и Windows, мы имеем различные способы обработки сторонних библиотек. В Linux мы создаем и сопоставляем версии, распространяемые с дистрибутивом CentOS/RHEL, что означает, что мы связываемся с релизными сборками, тогда как в Windows мы поддерживаем наши собственные пакеты сторонних библиотек, а в Windows мы создаем две версии каждой библиотеки - релиз версии, которая связывает msvcr100 и msvcp100 и отладочную версию, которая связывает msvcr100d и msvcp100d.

Мой вопрос заключается в том, нужно ли создавать отладочную версию зависимостей сторонних разработчиков от Windows или мы можем просто использовать/nodefaultlib: msvcr100 при построении отладочных сборников нашего собственного программного обеспечения.

Следующий вопрос: где я могу узнать о передовой практике в этом отношении. Я прочитал страницы MSDN о времени выполнения msvc, но в плане рекомендаций очень мало.

EDIT:

Позвольте мне перефразировать вопрос более сжато. С VS2010, в чем проблема с использованием/nodefaultlib: msvcr100 для связывания исполняемой сборки с/MDd при связывании с библиотеками, которые скомпилированы с/MD.

Моя мотивация для этого заключается в том, чтобы не создавать как выпускную, так и отладочную версию сторонних библиотек, которые я использую. Также я хочу, чтобы моя отладочная версия работала быстрее.

Из документа/MD,/MT,/LD (используйте Run-Time Library):

MD: Вызывает приложение для использования в multithread- и DLL конкретной версии пробега . Определяет _MT и _DLL и заставляет компилятор помещать имя библиотеки MSVCRT.lib в файл .obj.

Приложения, скомпилированные с этой опцией, статически связаны с MSVCRT.lib. Эта библиотека предоставляет слой кода, который позволяет компоновщику разрешать внешние ссылки. Реальный рабочий код содержится в MSVCR100.DLL, которая должна быть доступна во время выполнения для приложений, связанных с MSVCRT.lib

/MDD: Определяет _DEBUG, _MT и _DLL и вызывает приложение для использования отладки многопоточных - и DLL-специфичную версию библиотеки времени выполнения. Это также заставляет компилятор помещать имя библиотеки MSVCRTD.lib в файл .obj.

Таким образом, нет никакой документации о каких-либо различиях, связанных с сгенерированным кодом, отличным от _DEBUG.

Answer 1

Вы можете использовать сборку отладки CRT для отладки вашего приложения. Он содержит множество утверждений, которые помогут вам поймать ошибки в коде. You never отправьте отладочную сборку вашего проекта, всегда сборку выпуска. Вы также не можете, лицензия запрещает доставку msvcr100d.dll. Таким образом, создание проекта правильно автоматически исключает зависимость от отладочной версии CRT.

Опция/nodefaultlib linker была предназначалась, чтобы разрешить связывание вашей программы с пользовательской реализацией CRT. Довольно редко, но некоторые программисты много заботятся о создании небольших программ, а стандартный CRT не совсем мал.

Некоторые программисты используют/nodefaultlib, чтобы взломать проблему связи.Индуцируется, когда они связывают код, который был построен с настройками конфигурации Debug, с кодом, созданным с настройками конфигурации Release. Или код ссылки, который имеет несовместимые варианты CRT,/MD vs/MT. Это может работать, без гарантии, но, конечно, только подметает реальную проблему под ковриком.

Так что нет, это не правильный выбор, устранение основной проблемы должно быть вашей целью. Убедитесь, что все ваши файлы .obj и .lib построены с одинаковыми параметрами компилятора, и у вас не будет этой проблемы. Если это означает, что вам нужно приставать к владельцу библиотеки для правильной сборки, сначала попробуйте, взломайте его, только когда вы обнаружите, что больше не хотите иметь зависимость от этого .lib, но еще не имеете чтобы найти альтернативу.