Considérez ce scénario: Une demande de liens vers une bibliothèque tierce a.
A est construit à l'aide de MSVC 2008 et se lie statilement (c.-à-d. Construit avec / mt) à la bibliothèque d'exécution C Runtime V9.0.
L'application est construite à l'aide de MSVC 2005 et se lie statilement à A et (Utilisation / MT) à la bibliothèque d'exécution C Runtime V8.0.
Je peux voir problème 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.
est pris en charge pour conserver les en-têtes de la bibliothèque d'exécution compatibles entre les versions, ou si vous devez toujours s'assurer que toutes les bibliothèques liées statiquement liées sont liées à la même version de la bibliothèque d'exécution?
3 Réponses :
C'est un très mauvais plan. Éviter. Recompilez la bibliothèque en 2005 ou compilez l'application en 2008.
Ce qui me confond un peu, c'est qu'il y a probablement beaucoup d'applications liées aux anciennes libs 3ème parti (à leur tour reliant les anciens CRTS). Bien que je conviens que cela semble dangereux, cela ne semble pas être dangereux dans la pratique.
Pas une bonne idée du tout. Vous n'avez aucun contrôle sur les hypothèses effectuées par les bibliothèques d'exécution et la manière dont elles implémentent certains types. Cela va probablement créer un gâchis impie que non.
It devrait ne pas être un problème. Chaque bibliothèque lie à son propre runtime et fonctionne principalement de manière indépendante des autres bibliothèques du processus. Le problème se présente lorsque les bibliothèques abi sont mal définies. Si une sorte d'objet alloué en tas est alloué dans une bibliothèque, passée à travers une limite de la bibliothèque et «libérée» dans une autre bibliothèque, il y a des problèmes car différents gestionnaires de démarrage sont utilisés pour libérer un bloc du gestionnaire de démarrage utilisé pour allouer. ça.
Toute sorte de structure définie, d'objet ou d'une entité définie en C-Runtime ne doit pas être transmis à des limites d'accrocs lorsqu'une version d'exécution différente pourrait être utilisée: - Le fichier * obtenu d'une bibliothèque par exemple n'aura aucun sens à une autre bibliothèque liée contre un autre runtime.
Tant que l'API de la bibliothèque n'utilise que des types bruts, et n'essayez pas de libérer () passés à des pointeurs ou de transmettre des pointeurs à la mémoire de MALLOC interne () de la mémoire à laquelle ils attendent l'application (ou une autre bibliothèque) de libérer () Vous devriez être ok.
Son facile à tomber pour la FUD que "tout ce qui peut aller mal" si des roulements C C-RUNTIMES sont mélangés, mais vous devez vous rappeler que les libs et les bibliothèques dynamiques (.so / .dll / .dylib) ont été traditionnellement développées dans Une grande variété de langues: autorisant le code écrit dans ASM, C, C ++, Fortran, Pascal, etc. de communiquer via une interface binaire efficace de la CPU.
Pourquoi soudainement paniquer lorsque c est lié à C?