2009-03-27 8 views
7

Mon application (C++, multiplate-forme) utilise fortement les bibliothèques Boost (disons la version 1.x), et je veux également lier le SDK d'un tiers (fournisseur), lui-même en utilisant Boost (mais la version 1.y). Donc, nous lions tous deux dynamiquement contre notre propre version de DLLs Boost, CRT étant identique. Par conséquent, au moment de l'exécution, mon application devrait charger les deux DLL de Boost 1.x & 1.y.Est-ce que plusieurs versions d'une même DLL (Boost) peuvent coexister dans le même processus?

Quels sont les problèmes potentiels & gotchas associés?

Je ne peux pas modifier le SDK du fournisseur, mais je peux modifier mon application. Peut-être que je devrais essayer de lier statiquement contre mon Boost 1.x? PS: Le nom du DLL de Boost inclut leur version, donc aucune collision de nom, les deux sont identifiables. Pas l'habituel DLL-enfer.

Répondre

0

Si vous écrivez une fonction foo, et l'exportez à partir de F.dll, et une autre fonction foo exportée de G.dll, attendez-vous à des problèmes? Lorsque AF.exe est lié, l'éditeur de liens est dit: mettre du code là-dedans qui charge l'adresse de la fonction foo à partir de F.dll

Maintenant BG.dll est lié pour récupérer l'adresse foo de G.dll. Je ne vois toujours pas de problème.

Maintenant, remplacez AF.exe avec votre application, BG.dll avec l'application de votre fournisseur, F.dll avec votre version boost, G.dll avec la version boost du fournisseur. Conclusion: Je ne vois aucun problème si les noms de DLL sont différents.

2

En ce qui concerne l'utilisation des DLL pour différentes versions, il ne devrait pas y avoir de problème. Au moins pas sur Windows.

Ceci est vrai si le SDK utilise l'élévation interne. Si le SDK utilise des constructions boost dans son interface, par exemple: il a une fonction qui retourne un boost :: optionnel, puis avoir plusieurs versions peut causer des problèmes. Il pourrait encore fonctionner correctement, en fonction des changements entre les versions, mais ce sera certainement un risque. Je ne connais pas de bonne solution dans ce cas. Cela est également vrai si vous incluez un fichier d'en-tête SDK qui inclut un fichier d'en-tête boost.

2

Ceci est un gros problème. Faites une recherche sur DLL enfer.

Fondamentalement, la DLL (ou les bibliothèques partagées sous Linux) sont chargées, mais tous les noms ne sont pas résolus au moment du chargement. Qu'est-ce qui se passe est une évaluation paresseuse, de sorte que les noms sont évalués lors de la première utilisation. Le problème est que si 2 dll a le même nom alors l'emplacement où le nom est résolu dépend de l'ordre de recherche de la DLL (qui dépend de l'ordre de chargement).

Si vous établissez une liaison statique, vous n'aurez pas de problèmes avec les appels de méthode, car tous les vôtres seront résolus au moment de la compilation et le troisième sera résolu à l'exécution à partir de la DLL. Mais qu'en est-il des structures créées par boost de la version 1? Si vous les passez ensuite à la bibliothèque tierce qui les transmet ensuite à l'extension version-x. Les structures sont-elles disposées de la même manière?

Ceci est une zone très délicate et lorsque les problèmes se produisent très difficile à désamorcer. Alors essayez d'utiliser la même version.

Questions connexes