Почему библиотека времени выполнения является опцией компилятора, а не компоновщиком?

Question

Я пытаюсь создать статическую библиотеку C / C ++ с использованием Visual Studio 2005. Поскольку выбор библиотеки времени выполнения является опцией компиляции, я вынужден создать четыре варианта моей библиотеки, по одному для каждого варианта среды выполнения. библиотека:

• / MT - статическая библиотека времени выполнения
• / MD - библиотека времени выполнения DLL
• / MTd - отладка статической библиотеки времени выполнения
• / MDd - библиотека времени отладки DLL

Это параметры компилятора , а не параметры компоновщика. Исходя из фона Linux, это кажется странным. Разные библиотеки времени выполнения имеют разные соглашения о вызовах или что-то? Почему разные библиотеки времени выполнения не могут быть разрешены во время компоновки, т.е. когда я связываю приложение, использующее мою статическую библиотеку?

Answer 1

Эти параметры могут добавлять определения (например, __DLL и __DEBUG), которые используются в заголовочных файлах библиотеки времени выполнения. Одна общая вещь, которую нужно сделать, - это добавить __declspec (dllimport) к объявлениям функций при динамическом связывании.

Компилятор также, кажется, использует их, чтобы помочь компоновщику в связывании с правильными библиотеками. Это объясняется в MSDN .

Answer 2

Один побочный эффект определений препроцессора C, таких как _DLL и _DEBUG, которые упоминал Здан:

Некоторые структуры данных (такие как контейнеры и итераторы STL) могут иметь разные размеры во время выполнения отладки, возможно, из-за таких функций, как _HAS_ITERATOR_DEBUGGING и _SECURE_SCL. Вы должны скомпилировать свой код с определениями структуры, которые двоично совместимы с библиотекой, с которой вы связываетесь .

Если вы смешиваете и сопоставляете объектные файлы, которые были скомпилированы для разных библиотек времени выполнения, вы получите предупреждения компоновщика, такие как:

warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs

Answer 3

Компилятор должен знать, генерируете ли вы однопоточный или многопоточный код. По умолчанию компилятор генерирует потокобезопасный код (многопоточный). Вы должны указать это, если вам нужен однопоточный код. Если вы измените значение по умолчанию, компилятор изменит библиотеку времени выполнения по умолчанию (вы всегда можете переопределить это в параметрах команды компоновщика, просто убедитесь, что выбранная вами библиотека имеет тот же код структура как ваши объектные файлы: однопоточная статическая, многопоточная статическая или многопоточная DLL). Обратите внимание, что здесь нет опции однопоточной DLL (по определению библиотека DLL времени выполнения будет построена как поточно-ориентированная, так как она используется несколькими приложениями).

Answer 4

Если вы игнорируете статическую среду выполнения, вы получаете те же опции, что и в Linux.

Я знаю, что статическое время выполнения может быть полезным, но на самом деле оно мне никогда не было нужно. Кроме того, это приводит к потенциальным проблемам, связанным с распределением / освобождением памяти, и в результате я считаю, что проще просто использовать среду выполнения DLL.

Наличие версии Release / Debug аналогично Linux / Unix.
Хотя по соображениям эффективности я могу создать однопотоковые и многопоточные версии библиотек.

Answer 5

Существует разный машинный код, сгенерированный для DLL и статических библиотек.

И в Linux вы должны сделать то же самое, флаг компилятора называется -fPIC, если вы хотите создать общую библиотеку. В противном случае на AMD64 и SPARC (и, возможно, на других) произойдет сбой. В архитектуре i386 компоновщик достаточно умен и не разделяет библиотеку в памяти, поэтому он не падает.

Answer 6

Я полагаю, что причина этого в том, что код SEH (структурированный обработчик исключений) будет генерироваться по-разному, в зависимости от того, с какой библиотекой времени выполнения вы ссылаетесь.