Mise à jour 1.42 -> 1.54

Je travaille avec boost 1.42 sous VS2005 et VS2010.

J'ai voulu utiliser property_tree pour la 1ère fois et, patatras, une simple instanciation ne compile pas:
boost::property_tree::ptree pt;//ERROR

Il s'avère que property_tree ne compilait pas sous VS2010 avant une certaine version, donc je décide de faire la mise à jour et passer à boost 1.54.
J'ai juste remplacé le contenu du répertoire include qui contenait la 1.42. Très bien, ça compile, mais ça ne link plus :(

Un peu de recherche pour découvrir que maintenant il y a un auto_link sous windows avec VS (mais j'ai rien demandé moi, pourquoi imposer cela ?).
C'est un peu inutile je trouve si on n'utilise que les headers et qu'on n'a pas besoin des librairies qui nécessitent une compilation (c'est comme ça qu'on m'a vendu boost à l'époque: rien à compiler, #include du nécessaire et c'est tout !).

Bref, encore un peu de recherche et je déclare la macro BOOST_ALL_NO_LIB=1 dans les projets pour désactiver l'auto_link. Pas mieux :evilred:
Faut-il VRAIMENT compiler les librairies de boost maintenant ?
C'est fini le principe du "#include only" ?
Merci.

Bonjour,

Normalement non, l'auto-link ne cherche que les libs dont tu as utilisé un header qui peut en avoir besoin (c'est un #pragma comment). Ça concernait quel lib l'erreur de link ? Et tu utilises quoi comme en-tête de boost ?

unordered_set
unordered_map
preprocessor
Vraiment pas grand chose donc...

Le simple remplacement des header 1.42 par 1.54 génère 2 erreurs au link ("unresolved blablabla").
Seul changement (nécessaire) dans le projet: BOOST_ALL_NO_LIB=1


Et puis j'ai ajouté
property_tree/ptree
property_tree/xml_parser
property_tree/json_parser
Toujours avec BOOST_ALL_NO_LIB=1, des 10zaines d'erreurs au link cette fois (encore des "unresolved blablabla").

Bref, je comprends pas...

Oui, mais c'est quoi après les "unresolved" exactement, qu'est ce qu'ils essaient de linker/utiliser ? Et quel sont exactement les include que tu as utilisé ? Si tu utilises des includes "génériques" qui en incluent plein d'autre, ils peuvent inclurent des fichiers activant l'auto-link.

Bon, je ne retourne au boulot que lundi.

En attendant j'ai une ancienne version du prg sur mon pc à la maison (avec VS2010 seul).
Il est avec boost 1.47, uniquement les headers: ras.

Je viens de remplacer les headers par boost 1.54:
1>LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc100-mt-sgd-1_54.lib'

Une nuit plus tard :)

Désactivation de l'auto_link via la macro BOOST_ALL_NO_LIB=1.
Voici une erreur:

Code:

---

1>mycpp.obj : error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" referenced in function "public: class std::_Vector_const_iterator<class std::_Vector_val<..., ...> > & __thiscall std::_Vector_const_iterator<class std::_Vector_val<..., ...> >::operator++(void) ...

---

??? :cry:

Au cas où je devrais linker les .lib de boost, j'ai compilé de manière minimaliste comme trouver dans le guide rapide.

Code:

---

1 2	bootstrop.bat b2.exe

---

Comme chez moi je n'ai que VS2010, c'est suffisant (en apparence).

Je suppose que s'il y a plusieurs version de VS installées sur la même machine il faudrait faire quelque chose comme ceci.

Code:

---

1 2 3

bootstrop.bat b2.exe toolset=msvc-8.0 b2.exe toolset=msvc-10.0

---

Mais... car il y un mais.
Voici, par exemple, une des lib créées (chemin complet)

Code:

---

C:\SOFT\boost_1_54_0\bin.v2\libs\thread\build\msvc-10.0\debug\link-static\threading-multi\libboost_thread-vc100-mt-gd-1_54.lib

---

Pourquoi il n'y a pas le 's' de 'static' dans le nom ?
C'est pourtant bien un link static ?
Le projet (linker en static) réclame:

Code:

---

libboost_thread-vc100-mt-sgd-1_54.lib

---

Je conclus mes essais par une tentative d'inclusion des lib de boost dans le projet.
Voici le résultat:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

1>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "void __cdecl std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)" (?_Debug_message@std@@YAXPB_W0I@Z) already defined in libcpmtd.lib(stdthrow.obj) 1>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "void __cdecl std::_Xout_of_range(char const *)" (?_Xout_of_range@std@@YAXPBD@Z) already defined in libcpmtd.lib(xthrow.obj) 1>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "public: __thiscall std::_Container_base12::~_Container_base12(void)" (??1_Container_base12@std@@QAE@XZ) already defined in cmdparam.obj 1>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "public: __thiscall std::_Container_base12::_Container_base12(void)" (??0_Container_base12@std@@QAE@XZ) already defined in cmdparam.obj 1>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "public: void __thiscall std::_Container_base12::_Orphan_all(void)" (?_Orphan_all@_Container_base12@std@@QAEXXZ) already defined in cmdparam.obj 1>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "void __cdecl std::_Xlength_error(char const *)" (?_Xlength_error@std@@YAXPBD@Z) already defined in libcpmtd.lib(xthrow.obj) 1>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _strerror already defined in LIBCMTD.lib(strerror.obj) 1>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _memmove already defined in LIBCMTD.lib(memmove.obj) 1>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: "public: __thiscall std::exception::exception(char const * const &)" (??0exception@std@@QAE@ABQBD@Z) already defined in LIBCMTD.lib(stdexcpt.obj) 1>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: "public: virtual __thiscall std::exception::~exception(void)" (??1exception@std@@UAE@XZ) already defined in LIBCMTD.lib(stdexcpt.obj) 1>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: "public: __thiscall std::exception::exception(class std::exception const &)" (??0exception@std@@QAE@ABV01@@Z) already defined in LIBCMTD.lib(stdexcpt.obj) 1>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj) 1>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj) 1>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library

---

Je pense que j'ai besoin d'un peu d'aide pour 'bien' compiler boost.
Merci.

Pour le nommage des dll/lib de boost j'avais fait un post il y a quelques temps qui résume la situation. (En fait le nommage est tellement bizarre qu'à chaque que j'y suis confronté j'en ai déjà oublié le fonctionnement du coup je suis régulièrement obligé de googler mon propre post pour m'y retrouver, ça fait bizarre :aie:)
Enfin bref ça donne :

Citation:

---

Envoyé par Arzar

1) boost dynamique (.dll) / CRT dynamique (option /MD)
2) boost statique (.lib) / CRT dynamique (option /MD)
3) boost statique (.lib) / CRT statique (option /MT)

Par exemple en compilant la biblio boost system avec les trois configs ci-dessus on obtient :

1) boost_system-vc100-mt-1_51.dll
2) libboost_system-vc100-mt-1_51.lib
3) libboost_system-vc100-mt-s-1_51.lib

A noter que boost est farceur car dans tous les cas le nom contient un -mt qui semble indiquer une compilation avec l'option /MT alors que dans 2 cas sur 3 boost a en fait été compilé avec l'option /MD

---

Par défaut c'est la 2) qui est choisi sur un bootstrap.bat + b2.exe
Donc je pense que pour résoudre ces problèmes de link il faudrait déjà essayer de compiler ton appli principale en /MD.

(Ah oui et pour info il y a une option magique "b2.exe stage" qui permet de regrouper toutes les lib dans un même répertoire, c'est plus pratique que de devoir aller fouiner dans debug\link-static\threading-multi\nom_de_la_lib.)

Tu as essayé les options suivantes? :

Citation:

---

link=static|shared Whether to build static or shared libraries

---

et

Citation:

---

runtime-link=static|shared
Whether to link to static or shared C and C++
runtime.

---

Sinon pense aussi à faire b2 --help, ça donne quelques pistes sur les options de compilation par exemple:

Citation:

---

--build-type=<type> Build the specified pre-defined set of variations of
the libraries. Note, that which variants get built
depends on what each library supports.

-- minimal -- (default) Builds a minimal set of
variants. On Windows, these are static
multithreaded libraries in debug and release
modes, using shared runtime. On Linux, these are
static and shared multithreaded libraries in
release mode.

-- complete -- Build all possible variations.

---

Mais ce qui est bizarre justement c'est que normalement il n'y a pas à trafiquer avec les options link=static|shared, runtime-link=static, BOOST_ALL_NO_LIB=1 ou autre.

Sous windows un bootstrap + b2 stage génère les lib boost en statique et CRT dynamique (/MD) ce qui correspond exactement à ce que visual studio attends lorsqu'on crée un nouveau projet classique (console), qui est en /MD par défaut.

Il suffit alors normalement de rajouter dans VC++ directories\library directories un lien vers le répertoire contenant toutes les .lib boost et ça s'autolink tout seul.

Je viens de tilter également que les numéros de compilateurs chez visual ne correspondent pas à l'année: pour visual2010 ça doit être msvc-9.0.
Sinon dans le doute je ferai une compilation "complète stage" en laissant par défaut le compilateur pour vérifier celui qui est détecté par b2.

En règle générale ça ne correspond pas à l'année mais dans ce cas les étoiles se sont alignées car visual studio 2010 = msvc100 (mais ça n'aura pas duré longtemps car visual studio 2012 = msvc110) :aie:

Ah, ça, je sais (pour une fois) ;)

VS6 -> v6.0 -> #define _MSC_VER=1200
VS2003 -> v7.0, v7.1 (pas sûr pour celui-ci, il y eu des patchs) -> #define _MSC_VER=1300 et 1310
VS2005 -> v8.0 -> #define _MSC_VER=1400
VS2008 -> v9.0 -> #define _MSC_VER=1500
VS2010 -> v10.0 -> #define _MSC_VER=1600
VS2012 -> v11.0 -> #define _MSC_VER=1700

L'ordre est logique, ce sont les années qui ne le sont pas :mouarf:

Un header de boost pour vérifier:
http://www.boost.org/doc/libs/1_54_0...er/visualc.hpp

En fait il s'agit bien de la version du compilateur (c/c++), pas de l'IDE (visual studio).
Bon, alors hier soir, de fait, j'avais essayé
b2.exe /?
b2.exe -?
b2.exe ?
Et jamais aucune aide ne s'affichait, et pour cause :aie:
Vraiment, font pas tout comme y'faut ces gens-là.

Bon, je vais réessayer de faire un build complet.

Mais, pour en revenir au problème initial, il semble que "boost header only" c'est bien fini (?) :calim2:

Citation:

---

Envoyé par camboui

Bon, alors hier soir, de fait, j'avais essayé
b2.exe /?
b2.exe -?
b2.exe ?
Et jamais aucune aide ne s'affichait, et pour cause :aie:
Vraiment, font pas tout comme y'faut ces gens-là.

---

C'est de la mauvaise foi ... c'est écrit à la fin du bootstrap comment avoir l'aide de b2.

Citation:

---

Envoyé par camboui

Mais, pour en revenir au problème initial, il semble que "boost header only" c'est bien fini (?) :calim2:

---

Non, ce n'est pas fini. J'ai viré mon dossier stage de boost, j'ai pris le premier exemple de Boost.PropertyTree, ça a compilé sans aucun problème (boost 1.53).

Pas confondre "mauvaise-foi" et "ils-ont-des-yeux-et-ils-ne-voient-pas".

Code:

---

b2.exe link=static runtime-link=static

---

Résultat:

Code:

---

1 2	1>Time Elapsed 00:07:09.48 ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

---

Sinon, de fait, ce n'est pas propertry tree qui semblait forcer un link, plutôt un des containers unordered.

Même test avec unordered, même résultat.

C'est possible que des éléments de bibliothèques "header only" déclenchent des link quand elles estiment en avoir besoin, c'est à dire quand tu inclus (directement ou non) un header dont un des éléments à potentiellement besoin d'une bibliothèque non "header only". Typiquement si il y a un besoin de thread ou de serialization.

Le principe de l'auto-link est présent depuis pas mal de version dans boost (avant 1.42 je dirais). Il y a du avoir une modification dans une des bibliothèques que tu utilisent qui, malheureusement, influence ton code.

Mais quoiqu'il en soit, non, boost est toujours majoritairement header-only et seule une poignée de bibliothèques nécessite une compilation.

Citation:

---

Envoyé par camboui

boost/unordered_set.hpp
boost/unordered_map.hpp
boost/preprocessor.hpp

---

Outre les précités j'avais oublié celui-ci:
#include <boost/pool/pool_alloc.hpp>

J'ai réussi à compiler mon projet avec boost 1.54. Je n'ai plus cherché à voir "qui" m'empêche l'usage header only de boost.
En désactivant l'auto-link, seule une référence manque dans l'édition de lien:

Code:

---

unresolved external symbol class boost::system::error_category const & __cdecl boost::system::system_category(void)

---

Donc entre 1.42/1.47 et 1.54 il y a eu un changement quelque part. On verra plus tard lequel, ce n'est sans doute pas critique.

Merci à tous :D

J'ai une autre quesion...
J'ouvrirais bien un nouveau sujet, mais bon, ça ne vaut p-ê pas la peine pour si peu ;)

Je parse du XML dont voici un contenu:

Code:

---

<name>Max Baucus<name>

---

Je fais donc

Code:

---

std::string name=pt.get<std::string>("name");

---

qui me renvoit

Code:

---

Max Baucus

---

:calim2: (même le forum "casse" le contenu lors de l'édition)