C ++ Visual Studio библиотеки

Question

Есть ли способ сделать статические библиотеки, встроенные в Microsoft Visual Studio, независимыми от используемого CRT (с поддержкой отладки / без нее)?

Я имею в виду, что для простой библиотеки C можно сгенерировать код, используя gcc, а затем использовать ту же статическую библиотеку в Visual Studio. Полученный файл library.a полностью независим от переключателей /MT или /MDd и не приводит к ошибкам предупреждения / связывания.

По сравнению с поведением по умолчанию в Visual Studio вам придется создавать две версии одной и той же библиотеки - для режимов отладки / выпуска независимо. Если вы попытаетесь использовать версию Release в конфигурации отладки или наоборот, это приведет к появлению уродливых предупреждений (warning LNK4098: defaultlib "LIBCMT" ...), но иногда не компилируется из-за разного времени выполнения?

Есть ли способ избежать этого? Или, возможно, я что-то не так делаю?

Answer 1

Для создания библиотеки, которая будет ссылаться независимо от выбора времени выполнения, необходимо использовать два параметра:

/ MT для сборки в сравнении с базовой версией выпуска, / Zl , чтобы опустить имена библиотек по умолчанию.

Сборка с использованием времени выполнения dll приведет к тому, что компилятор украсит все символы времени выполнения с помощью __imp_ (поэтому, например, он попытается связать __imp__fread вместо _fread). Поэтому вы должны выбрать одну из статических сред выполнения.

Компилятор делает неявную прагму библиотеки по умолчанию, в зависимости от выбранной библиотеки:

#pragma comment(lib,"libcmtd.lib")

так выглядит в коде. / Zl заставляет компилятор опустить все эти директивы - (неявные и явные) из результирующего файла .obj (и, следовательно, .lib). Таким образом, результат должен связываться чисто, не вызывая конфликтов библиотеки по умолчанию.

Answer 2

Есть ли проблема с распространением 2-х версий библиотеки? Я не претендую на то, чтобы говорить за всех, но мне всегда нравится иметь отладочную версию, скомпилированную со статическими отладочными библиотеками, с утверждениями и дополнительной проверкой. (Символы тоже хороши, конечно!) полезны, трассировка стека обычно лучше, когда происходит сбой в коде библиотеки, и часто легче прочитать разборку.

Answer 3

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