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.