Как правильно собрать стороннюю библиотеку для использования в конфигурациях Debug и Release в моем проекте?

Question

Когда мне нужно собрать какую-нибудь стороннюю библиотеку для использования в нескольких моих проектах под другой версией MSVC, я обычно собираю ее для каждой версии MSVC и для обеих Отладка и освободить конфигурации. Это то, что делает повышение, и это то, что мы сделали за всю свою жизнь в моей команде.

Тем не менее, я до сих пор не понимаю, почему я не могу просто собрать эту библиотеку, как ... что угодно. Все, что мне нужно, это прототип функции и объектный код, верно? Поскольку я связываю ЭЛТ статически, у меня нет внешних зависимостей. Но когда я пытаюсь связать библиотеку, встроенную в Release под MSVC8, с моим проектом в Debug под MSVC10, у меня появляются эти «уже определенные» ошибки компоновщика, которые мы все так ненавидим.

Но почему? Могу ли я просто «инкапсулировать» все эти функции в lib и не экспортировать их, чтобы мой проект извлек из библиотеки только то, что ему нужно? Почему у меня может быть предварительно скомпилированная версия libpng и zlib, которую я могу связать в каждом проекте? Да, я думаю, они не создаются с использованием MSVC, но все еще используют те же функции CRT. Так может кто-нибудь объяснить подробно или поделиться ссылкой на просвещенное объяснение этой проблемы?

Answer 1

Поскольку я статически связываю ЭЛТ, у меня нет внешних зависимостей

Ну, это не правда, у вас есть зависимость. На статической версии ЭЛТ. Отладка или выпуск, в зависимости от ваших настроек сборки. И это внешняя зависимость, компоновщик склеивает CRT позже, когда библиотека становится связанной. Код, который использует библиотеку, также зависит от CRT. И если настройки компиляции не совпадают, тогда компоновщик barfs.

Вы изолируете эту зависимость, создавая DLL вместо статической библиотеки ссылок. Кроме того, вы должны убедиться, что экспортируемые функции не вызывают зависимость CRT. Вы не можете вернуть объект C ++ из стандартной библиотеки C ++ и не можете вернуть указатель на объект, который должен быть освобожден клиентским кодом. Даже передавать структуры сложно, потому что их упаковка - это деталь реализации, но вам обычно это не нравится. Хорошим практическим примером является автоматизация COM, она заставляет вас использовать подмножество типов, которые являются универсальными. Windows изобилует ими, и все эти серверы работают с любой версией компилятора или CRT. Даже на любом языке. Это, однако, обходится дорого, написание такой библиотеки не так просто и удобно, как просто бросить кучу кода в статическую библиотеку.