Discussion :

[oodini]

Hello,

Je développe une lib qui elle-même fait appel à deux libs externes, qui sont bien évidemment compilées avec des versions différentes de gcc.

Est-ce gênant ? Avec quelle devrais-je compiler ?

Merci.

[dourouc05]

Bonjour,

Si tu mélanges des versions de GCC, tu commences à mélanger des versions du runtime (en gros, la libc/STL/..., quand c'(est compilé), et c'est source de problèmes, parfois assez gênants, et assez durs à retrouver. Donc, tant que c'est possible, n'utilise qu'un seul et unique compilateur par app, sinon... Je plaide non coupable quand tu auras jeté ton PC par la fenêtre.

Niveau solution, il ne reste que la recompilation de toutes les libs...

[oodini]

Ce n'est pas vraiment une solution, puisque je suis tenu par les c* par les les développeurs des bibliothèques externes...

Je crois qu'il en reste que le PC balancé par la fenêtre.

[Mac LAK]

On peut mélanger (en partie) les runtimes, mais c'est effectivement une pente assez glissante...

La seule solution (presque) fiable consiste à écrire une librairie d'encapsulation / isolation complète de l'une ou l'autre librairie (idéalement, les deux, vus qu'ils semblent peu réactifs). Cette encapsulation devra exposer une interface abstraite de TOUS les éléments issus de la CLib et/ou de la STL, et implémenter les fonctions d'allocation / libération pour TOUS les éléments dynamiques.

En clair, cela veut dire par exemple :

• Ces librairies d'encapsulation devront être au format SO / DLL.
• Pour une fonction renvoyant un std::string, par exemple, tu exposeras un char* (et sa longueur) au niveau des fonctions.
  Tu fourniras dans un .H séparé une macro / template pour le "recomposer" en un std::string valide au niveau de l'application. Interdiction de le faire dans un code compilé dans la librairie d'abstraction.
  Ce principe est valable pour TOUS les containers STL.
• L'application ne devra soit JAMAIS allouer les données ni les libérer, soit TOUJOURS les allouer ET les libérer. Aucun "mix" ne doit être fait, car le "free / delete" d'une version de GCC n'est pas forcément binairement compatible avec le "malloc / new" d'une autre version.
• Tu devras passer par un format "portable" pour tout ce qui n'est pas directement issu de la plate-forme sur laquelle tu travailles.

Alors OK, c'est faisable... Ceci étant dit, c'est une usine à gaz.

Après, faudrait savoir ce que font ces librairies. Car tu peux peut-être déjouer tout ça si elles peuvent tourner dans d'autres processus, que tu pourrais interconnecter avec ton programme au travers d'une librairie comme ICE qui t'aidera à abstraire les éléments non-portables.
Si tu dois absolument les avoir DANS ton processus, c'est mal barré sans passer par des librairies d'abstraction / isolation comme je te les ai décrites ci-dessus.