Absence des versions Multithreaded, static runtime dans les lib de boost 1.4.2

**masterx_goldman** · 15/02/2010, 14h26

Bonjour tout le monde,

J'ai voulu installer la version 1.4.2 de boost en utilisant le tuto suivant:

http://arb.developpez.com/c++/boost/install/vc++/

ce qui m'a mis sur le lien suivant: http://www.boostpro.com/download

J'utilise VC++ 9.0 ( VS2008 ), quand je coche les versions de la RunTime :

* Multithread
* Multithread Debug
* Multithread, static runtime
et puis quand je passe à l'installation des .lib associées, je ne trouve l'option la plus importante pour le release qui est la Multithread, static runtime que pour VC++ 7.1 , par contre pour VC++ 8.0 ET 9.0 non

Voir la figure associée

Est ce que celà signifie que ces lib n'existe pas pour VC++ 9.0 ? Déja je vois que même pour VC++ 8.0 elles n'existent pas !

Merci de m'expliquer ce que je dois faire.

**dragonjoker59** · 15/02/2010, 14h37

Eh bien il va falloir que tu compiles boost toi même ! (ou du moins, que tu demandes à bjam de le faire).
Pour cela, télécharges les sources de la version de boost que tu veux (apparemment 1.4.2). Dedans, tu devrais avoir un truc qui s'appelle bjam.exe.
Tu le mets à la racine du répertoire de boost. Vérifie que tu as bien les fichiers boost-build.jam et Jamroot dans le même dossier. Ensuite il faut que tu modifiez le fichier Jamroot, et que tu changes 'build-type' qui vaut normalement 'minimal'. Tu le mets à 'complete', tu lances bjam, et tu reviens 2h plus tard ^^

**Mat007** · 17/02/2010, 22h47

Salut,

Non le binaire bjam ne fait pas partie de la distribution des sources, mais il est facile de le compiler :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
cd ./tools/jam/src
./build.bat

(depuis la racine extraite de l'archive des sources)

Ensuite pour compiler tu peux par exemple tenter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./tools/jam/src/bin.ntx86/bjam.exe --toolset=msvc-7.1 --toolset=msvc-8.0 --toolset=msvc-9.0 --build-type=complete runtime-link=static threading=multi stage

(toujours depuis la racine extraite de l'archive des sources)

MAT.

**masterx_goldman** · 23/02/2010, 00h22

Envoyé par Mat007

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
cd ./tools/jam/src
./build.bat

(depuis la racine extraite de l'archive des sources)

Ensuite pour compiler tu peux par exemple tenter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./tools/jam/src/bin.ntx86/bjam.exe --toolset=msvc-9.0 --build-type=complete runtime-link=static threading=multi stage

Merci ça a marché

Maintenant, si je veux builder les versions suivantes en même temps ou même en séquence, quelle options j'aurai à écrire ?

Multithreaded : LIB statique Release (/MD) - Utilisé par défaut en Release
Multithreaded Debug : LIB statique Debug (/MDd) - Utilisé par défaut en Debug
Multithreaded, static runtime : LIB statique Release, CRT statique (/MT) - Recommandé en Release

J'ai trouvé dans le help de bjam les propriétés suivantes:

Properties:

toolset=toolset Indicates the toolset to build with.

variant=debug|release Select the build variant

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

threading=single|multi Whether to build single or multithreaded binaries

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

Mais je sais pas comment les utiliser pour générer les lib ( /MD et /MDd )

Merci de m'expliquer comment je devrais faire

**Mat007** · 23/02/2010, 00h42

Euh ok, je vois mal ce qu'il te manque mais bon je vais te faire le premier :

Multithreaded : LIB statique Release (/MD)

En décomposant :
Multithreaded -> threading=multi
LIB statique -> link=static
Release -> variant=release
CRT pas statique -> runtime-link=shared

Et en mettant ça bout à bout sur une seule ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./tools/jam/src/bin.ntx86/bjam.exe --toolset=msvc-9.0 threading=multi link=static variant=release runtime-link=shared stage

Ensuite tu vas voir dans ./stage/lib et voilà.
(c'est peut-être ça qu'il te manquait en fait, le répertoire de sortie ?)

Sinon si tu veux pas t'embêter à sélectionner tu dois pouvoir faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./tools/jam/src/bin.ntx86/bjam.exe --toolset=msvc-9.0 stage

Pour que ça te fasse plus ou moins toutes les variantes...

MAT.

**guillaume07** · 20/03/2010, 11h36

une question tiens concernant les binaires de lib dit "multithread"

c'est quoi au juste, juste des binaires qui sont thread safe ?

**bruno_pages** · 20/03/2010, 12h44

Envoyé par guillaume07

c'est quoi au juste, juste des binaires qui sont thread safe ?

une autre façon de le dire est que leur code est réentrant, c.a.d. qu'une commutation de thread ne les perturbe pas.

un code n'est pas réentrant s'il utilise des données globales (partagées par les threads) et que leur manipulation n'est pas protégée par un mutex ou équivalent

voici un exemple de code non réentrant pour bien faire comprendre (pas la peine de me dire qu'il fallait que aux soit une variable locale de swap, qu'il fallait utiliser une classe template pour rendre la chose générique etc

)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
int aux;
 
void swap(int & a, int & b)
{
  aux = a;
  a = b;
  b = aux;
}

si un premier thread utilise swap et est interrompu après l'affectation de aux et avant celle de b par un autre thread lui aussi appelant swap alors la valeur en sortie de b pour le premier thread ne sera pas celle qu'avait a dans ce thread mais celle de a issue du second thread

**guillaume07** · 20/03/2010, 14h19

ok je vois, mais now j'ai le doute entre réentrant vs tread safe

Notamment pourquoi une fonction thread-safe n'est pas forcément réentrante ?

**bruno_pages** · 20/03/2010, 15h09

Envoyé par guillaume07

Notamment pourquoi une fonction thread-safe n'est pas forcément réentrante ?

mais non, thread-safe == réentrant

**guillaume07** · 20/03/2010, 15h34

j'ai besoin d'un vrai connaisseur merci

**guillaume07** · 20/03/2010, 18h46

ok donc en faite, si une fonction qui utilise une variable globale, utilise des locks pour devenir thread-safe cela la rend non réentrante car un seul thread peut y accéder. Alors que si une fonction est réetrrante ie: n'utilise pas de variable global ( cela inclut les données statiques ) elle est forcément thread-safe.

donc à priori les binaires d'une lib multithread ne sont pas nécéssairement réentrants

**yan** · 20/03/2010, 21h12

Salut

Envoyé par bruno_pages

mais non, thread-safe == réentrant

Attention, thread-safe et réentrant c'est pas la même chose... c'est deux notions différentes.
Et tu trouve une panoplie de définition simplifié en fonction du contexte.

En gros (et c'est surement encore simplifié):

réentrance : une fonction qui n'utilise dans son implémentation que des variables n'appartenant qu'au thread qui l'exécute.
thread safe : une fonction qui peut être appeler par plusieurs thread sans aucune contrainte.

Une plus complète :
http://publib.boulder.ibm.com/infoce..._safe_code.htm

La définition dans Qt est plus simple à comprendre(Attention, c'est une simplification de leur définition adapté à son cas) :

Re-entrant : une fonction est dite reentrante si l'appel à cette fonction peut être appelé par différente thread sur des données unique. Une fonction appartenant à une classe, peut être appeler par différente thread uniquement si l'instance de la classe est différente pour chaque thread.
Thread safe : une fonction est dite threadsafe si l'appel à cette fonction peut être appelé par différente thread sur une donnée partagé. Contrairement à la notion de re-entrance, une fonction appartenant à une classe, peut être appeler par différents threads avec une même instance de la classe.