Ошибка ссылки: xxx уже определяется в *****.LIB:: Что точно является неправильным?

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

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

В старых версиях Visual Studio были однопоточные библиотеки (выпускная и отладочная версии) помимо многопоточных библиотек (выпускная и отладочная версии). Для своего проекта вы можете притвориться, что однопоточных библиотек никогда не существовало.

Если вы поэкспериментируете со случайными способами заставить компоновщик отключиться и оставить проблемы, которые будут обнаружены вашими клиентами, а не вами, вы можете обнаружить, что параметр / NODEFAULTLIB сделает это. Создатели библиотеки DCMTK предупреждают вас не делать этого, потому что некоторые другие люди делали то же самое в прошлом.

Что случилось с «режимом отладки» (многопоточная отладка) и «режимом выпуска» (многопоточность)? Что именно происходит под капотом? Почему именно это вызывает ошибку компоновки?

Это разные версии библиотеки времени выполнения C. Вы можете статически связываться с библиотекой времени выполнения в режиме отладки и выпуска. В параметрах генерации кода (упомянутых ниже) это будут «Многопоточная отладка» и «Многопоточная отладка». Параметры «Многопоточная DLL отладки» и «Многопоточная DLL» динамически связываются со средой выполнения C. Путем динамического связывания со средой выполнения вам также придется отправить установщик, настроенный для установки распространяемого пакета VC, который содержит соответствующие библиотеки DLL среды выполнения для вашей версии Visual C ++.

Статическая связь со средой выполнения C обычно не одобряется, даже Microsoft :

В дополнение ко всем методам , описанным выше для распространения Visual C ++ библиотеки DLL, есть последний вариант для создания вашего приложения, при котором не требуется распространять библиотеки DLL.Однако этот параметр работает только для нативного кода (он не поддерживается с / clr) и делает ваших клиентов серьезно уязвимыми для любых дыр в безопасности. поскольку также ложится серьезным бременем на себя исправлять все клиентские системы в случае обнаружения уязвимости в какой-либо из библиотек. Эта опция предназначена для статической компоновки библиотек как файлов .lib вместо динамической загрузки их как DLL. Для этого нужно использовать флаг / MT в командной строке cl.exe (vs / MD) или выбрать соответствующий параметр в своем проекте properties через Visual Studio. Вы можете использовать эту опцию при тестировании ранних отладочных сборок вашего приложения на тестовых машинах перед началом работы по настройке. [См. сноску 3]

Однако я не могу придумать сценария , в котором это было бы правильным действием при отгрузке вашего продукта клиентам. По сути, этот подход извлекает двоичный код , необходимый из файлов .LIB во время компиляции , делая его частью вашего .exe или .dll файлы. Это увеличивает размер вашего приложения, и нет никакого способа обновить библиотеки, кроме перекомпиляции вашего приложения с новыми .LIBs и распространения вашего { {1}} сначала. Это означает, что если вы не коснетесь каждой машины, на которой установлено ваше приложение, каждый раз обнаруживается уязвимость системы безопасности в библиотеках Visual C ++ и полностью переустановите обновленные двоичные файлы , вы оставите своих клиентов уязвимыми для атак.Если вместо этого вы используете библиотеки DLL, каждый раз в библиотеках Visual C ++ обнаруживается уязвимость системы безопасности , Microsoft установит обновление {{1} } централизованно в папку WinSxS через Центр обновления Windows, и все запросы на библиотеки DLL будут перенаправляться на обновленную версию. Это снимает все бремя обслуживания с вашей стороны, а также позволяет пользователю установить одно небольшое обновление, которое затронет все его приложения вместо замены {{1} }} каждый установленный exe и DLL в их системе . Пожалуйста, не распространяйте приложение, созданное путем статического связывания с библиотеками Visual C ++ , если у вас нет системы для обновления каждого клиента {{1 }} машина, а также имеет очень вескую причину для этого. В настоящее время я не могу придумать ни одного обстоятельства, при котором это было бы правильным решением для приложения доставки.

Интересно, есть ли что-то под названием «Однопоточная отладка» и «Однопоточная отладка», которая снова вызывает то же самое.

Нет, см. Выше.

В документации что-то говорится о «Опциях генерации кода». Какие варианты генерации кода? Зачем они?

Щелкните правой кнопкой мыши свой проект Visual C ++ (из Visual Studio) и выберите "Свойства". В разделе «Свойства конфигурации» -> «C / C ++» -> «Генерация кода»

документация специально предупреждает нас не использовать обходной путь / NODEFAULTLIB. (пример / NODEFAULTLIB: msvcrt). Почему? Как я могу доставить неприятности? что это такое?

Послушай их совет и не делай этого.

Пожалуйста, объясните последний пункт документации для пользователей MFC. Потому что я собираюсь использовать MFC позже в этом проекте.Объясните, зачем нам это делать? Какие проблемы это вызовет, если я этого не сделаю.

Поскольку MFC динамически связан со средой выполнения C, использование библиотек, которые статически связаны со средой выполнения C, вызовет ошибки компоновщика, которые вы указали первыми в своем сообщении.

Хотите еще что-нибудь упомянуть? Я имею в виду подобные ошибки. Меня очень интересует Linker и его проблемы. Итак, если есть какие-то похожие вещи, вы можете их упомянуть или хотя бы несколько ключевых слов.

По моему опыту, всегда динамически подключайтесь к среде выполнения C.Обычно это избавляет вас от многих головных болей, подобных той, которую вы испытываете прямо сейчас.