Discussion :

[Tan Phi]

Bonjour,

Je rencontre un problème assez étrange en voulant linker mon programme sous Visual C++ 2008. Il me sort des erreurs me disant que certains symboles de boost::filesystem::path sont déjà définis ailleurs, dans une autre librairie. Bien évidemment, cela est complètement faux. D'ailleurs le problème n'apparaît que si je lie dynamiquement avec Boost, statiquement, tout est OK.

Pour l'instant je m'en sors en ajoutant /FORCE:MULTIPLE à mes options de link, mais je ne considère pas ça comme une solution correcte car cela pourrait occulter un jour de véritables erreurs.

Auriez-vous des indications sur ce problème ? Merci

[bacelar]

que certains symboles de boost::filesystem::path sont déjà définis ailleurs, dans une autre librairie. Bien évidemment, cela est complètement faux.

Vous faites une grossière erreur, ce type de problème a toujours pour source un truc entre la chaise et le clavier.

Normalement, le linker indique les fichiers lib ou obj qui contient les choses en conflits.

C'est quoi précisément le message d'erreur ?

[Tan Phi]

Il s'agit d'une erreur LNK2005. Je n'ai pas le message en tête comme ça (et je ne suis pas au boulot pour vous le poster tout de suite), mais pour résumer, le message indique que boost::filesystem::~path est déjà défini dans Runtime.obj, cet objet faisant partie d'une autre librairie développée en interne par ma boîte.

Même problème ensuite avec boost::filesystem::string. En debug, il y en a un troisième qui apparaît, mais j'ai oublié lequel.

En écrivant ces mots, je pense avoir deviné le problème : Boost.Filesystem doit être lié statiquement à cette librairie interne. Mon programme qui utilise cette librairie, ainsi que filesystem directement (mais lié dynamiquement), y voit donc une double définition.

Cela transforme un peu ma question et sort du cadre du forum VC++, mais je pose au cas où : comment faire comprendre à CMake qu'on veut lier statiquement boost, sauf une librairie (en l'occurence Boost.Thread) ? La variable Boost_USE_STATIC_LIBS ne permet que de faire tout l'un ou tout l'autre. J'ai tenté de définir BOOST_THREAD_DYN_LINK pour le préprocesseur, mais ça n'a pas fonctionné.

Pour répondre tout de suite à la question de pourquoi je fais un truc pareil, c'est parce que malheureusement, j'ai des MFC un peu partout dans le programme. Boost.Thread lié statiquement avec les MFC pose des problèmes, mais dynamiquement c'est OK (cf http://www.juicydata.com/LinkingMfcAndBoostThread).

J'ai bien conscience que la meilleure solution serait de prendre le temps de virer tous les MFC, mais ça prendrait trop de temps et mon employeur ferait les gros yeux. ;-)

Merci en tout cas de vous pencher sur mon problème.

[bacelar]

Heu, pourquoi ne pas faire de Runtime une Dll ?

P.S.: Une dette technique, faut toujours la payer, alors virer les MFC si vous n'en avez pas besoin.

[Tan Phi]

Oui j'y ai pensé après avoir posté mon dernier message. C'est sûr que ça devrait marcher. La seule chose qui me retient de le faire n'est pas un problème technique, mais un problème de travail en équipe. En faisant cela, je vais aller à l'encontre de la pratique courante dans ma boîte (ce sera même à ma connaissance un cas unique) et comme je ne serai pas le mainteneur de ce projet, ça ne fera qu'amener de la confusion chez les autres. Autant aller vers le plus simple et le plus facile à maintenir.

Je pense que je vais aller voir mon chef et tenter de le convaincre que l'effort de virer les MFC en vaut la peine.

Je passe la discussion en résolue. Après tout ma question initiale l'est. ;-)
Merci en tout cas d'avoir réfléchi à mon problème.