Библиотека времени выполнения не соответствует и VC ++ - О, несчастье!

Question

Кажется, что всю свою взрослую жизнь меня мучил компоновщик VC ++, который жаловался или баловался, потому что разные библиотеки не пришли к единому мнению, какую версию библиотеки Runtime использовать. Я никогда не в настроении осваивать этот мрачный предмет. Поэтому я просто пытаюсь возиться с этим, пока он не сработает. Сообщения об ошибках никогда не бывают полезными. Также нет документации Microsoft по этому вопросу - по крайней мере, для меня.

Иногда он не находит функции - потому что искажение имени не то, что ожидалось? Иногда он отказывается смешивать и сочетать. В других случаях он просто говорит: "LINK: предупреждение LNK4098: defaultlib 'LIBCMTD' конфликтует с использованием других библиотек; используйте / NODEFAULTLIB: library" Использование / NODEFAULTLIB не работает, но предупреждение кажется мягким. Какого черта "DEFAULTLIB" в любом случае? Как решает линкер? Я никогда не видел способа указать компоновщику, какую библиотеку времени выполнения использовать, только как сообщить компилятору, для какой библиотеки создаются вызовы функций.

Существуют программы "обхода зависимостей", которые могут проверять объектные файлы, чтобы увидеть, от каких DLL они зависят. Я только что запустил один проект, который пытаюсь создать, и это настоящий беспорядок. Существуют системные .libs и .dll, которые хотят конфликтующих версий времени выполнения. Например, COMCTL32.DLL хочет MSVCRT.DLL, но я связываюсь с MSVCRTD.DLL. Я ищу, чтобы увидеть, есть ли COMCTL32D.DLL, даже когда я печатаю.

Так что я думаю, что я прошу учебник о том, как разобраться в этих вещах. Что ты делаешь и как ты это делаешь?

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

1. Параметры: Отладка / Выпуск, Многопоточный / Однопоточный и Статический / DLL. Только шесть из восьми возможных комбинаций покрыты. Не существует однопоточной библиотеки DLL, ни Debug, ни Release.

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

Бонусный вопрос: как кто-то или любая компания может создать такой беспорядок?

Answer 1

Ваши очки (1) и (2) выглядят правильно для меня. Еще одна вещь, которую следует отметить с помощью (2), это то, что связывание в отладочном CRT также дает вам доступ к таким вещам, как расширенная проверка кучи, проверенные итераторы и другие различные проверки работоспособности. Однако вы не можете распространять отладочный CRT вместе с вашим приложением - вы должны отправлять его только с использованием сборки выпуска. Мало того, что это требуется лицензией VC, но вы, вероятно, не хотите отправлять отладочные файлы в любом случае.

Нет такой вещи как COMCTL32D.DLL. Библиотеки DLL, которые являются частью Windows, должны загружать CRT, с которым они были связаны при сборке Windows - это включено в ОС как MSVCRT.DLL. Эта Windows CRT полностью независима от Visual C ++ CRT, который загружается модулями, входящими в вашу программу (MSVCRT.DLL - это тот, который поставляется с Windows. VC CRT будет содержать номер версии, например, MSVCRT80.DLL). Отладочные / выпускные многопоточные / однопоточные параметры влияют только на файлы EXE и DLL, составляющие вашу программу.

Лучшая практика в IMO - выбирать настройки для вашего ЭЛТ и стандартизировать их для каждого двоичного файла, который вы отправляете. Я бы лично использовал многопоточную среду выполнения DLL. Это связано с тем, что Microsoft может (и делает) выпускать обновления безопасности и исправления ошибок для CRT, которые можно вытолкнуть через Центр обновления Windows.