Lier statiquement une bibliothèque construite avec une version différente de la bibliothèque d'exécution C, c'est bien ou c'est mal ?

Question

Considérez ce scénario : Une application établit un lien avec la bibliothèque A d'un tiers.

A est construit en utilisant MSVC 2008 et est lié statiquement (c'est-à-dire construit avec /MT) à la C Runtime Library v9.0.

L'application est construite en utilisant MSVC 2005 et est liée statiquement à A et (en utilisant /MT) à la bibliothèque d'exécution C v8.0.

Je peux imaginer des problèmes avec cela, par exemple si les types sont modifiés dans les en-têtes entre les versions de la bibliothèque d'exécution.

Prend-on soin de garder les en-têtes de la bibliothèque d'exécution compatibles entre les versions, ou doit-on toujours s'assurer que toutes les bibliothèques liées statiquement sont liées à la même version de la bibliothèque d'exécution ?

Answer 1

Il debe ne sera pas un problème. Chaque bibliothèque est liée à son propre runtime et fonctionne en grande partie indépendamment des autres bibliothèques du processus. Le problème survient lorsque l'ABI des bibliothèques est mal définie. Si un objet alloué au tas est alloué dans une bibliothèque, passé à travers une frontière de bibliothèque et "libéré" dans une autre bibliothèque, il y aura des problèmes car un gestionnaire de tas différent de celui utilisé pour l'allouer est utilisé pour libérer un bloc.

Tout type de structure, d'objet ou d'entité défini par c-runtime ne doit pas être transmis au-delà des frontières où une version différente du runtime pourrait être utilisée : les FILE* obtenus à partir d'une bibliothèque par exemple n'auront aucune signification pour une bibliothèque différente liée à un runtime différent.

Tant que l'API de la bibliothèque n'utilise que des types bruts, et n'essaie pas de libérer() des pointeurs transmis, ou de transmettre des pointeurs à la mémoire malloc() interne qu'ils attendent que l'application (ou une autre bibliothèque) libère(), tout devrait bien se passer.

Il est facile de tomber dans le piège du FUD selon lequel "tout peut mal tourner" si les temps d'exécution c sont mélangés, mais il faut se rappeler que les librairies et les bibliothèques dynamiques (.so / .dll / .dylib) ont traditionnellement été développées dans une grande variété de langages : permettant au code écrit en asm, c, c++, fortran, pascal etc. de communiquer via une interface binaire efficace pour le CPU.

Pourquoi paniquer soudainement quand C est lié à C ?

Answer 2

C'est un très mauvais plan. A éviter. Soit vous recompilez la bibliothèque en 2005, soit vous compilez l'application en 2008.

Answer 3

Ce n'est pas du tout une bonne idée. Vous n'avez aucun contrôle sur les hypothèses faites par les bibliothèques d'exécution et sur la façon dont elles implémentent certains types. Il est plus probable que cela crée un désordre impie que le contraire.