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

Рассмотрим этот сценарий: Приложение ссылается на стороннюю библиотеку A.

A строится с использованием MSVC 2008 и статически связывается (т. е. построен с /MT) в библиотеку времени выполнения C v9. 0.

Приложение построено с использованием MSVC 2005 и статически связывается с A и (используя /MT) с библиотекой времени выполнения C v8.0.

Я вижу проблемы с этим - например, если типы изменяются в заголовках между версиями библиотеки времени выполнения.

Заботится о сохранении времени выполнения заголовки библиотек совместимы между версиями, или всегда нужно убедиться, что все статически связанные библиотеки ссылаются на одну и ту же версию библиотеки времени выполнения?

3 9
c++ visual-c++ static-linking

3 ответа:

Это должен не будет проблемой. Каждая библиотека ссылается на свою собственную среду выполнения и в основном функционирует независимо от других библиотек в процессе. Проблема возникает, когда библиотеки ABI плохо определены. Если какой-либо выделенный объект кучи выделяется в одной библиотеке, передается через границу библиотеки и "освобождается" в другой библиотеке, возникают проблемы, так как другой менеджер кучи используется для освобождения блока от менеджера кучи, используемого для его выделения.

Любой вид структуры, объекта или сущности, определяемой c-runtime, не должен передаваться через границы, где может использоваться другая версия среды выполнения : - файл*, полученный, например, из одной библиотеки, не будет иметь значения для другой библиотеки, связанной с другой средой выполнения.

До тех пор, пока API библиотеки использует только необработанные типы, и не пытайтесь освободить (), переданные в указателях, или передать указатели во внутреннюю память malloc () ' d, которую они ожидают, что приложение (или другая библиотека) освободит () вас все должно быть в порядке.

Легко поддаться на FUD, что "все может пойти не так", если c-runtimes смешаны, но вы должны помнить, что библиотеки и динамические библиотеки (. so / .файл DLL / .dylib) традиционно разрабатывались на самых разных языках: позволяя коду, написанному на asm, c, c++, fortran, pascal и т. д., объединяться через эффективный двоичный интерфейс CPU efficient.

Почему вдруг паника, когда C связан с C?

13

Это очень плохой план. Избегать. Либо перекомпилируйте библиотеку в 2005 году, либо скомпилируйте приложение в 2008 году.

3

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

0