Linker filesystem en static

Je voudrais intégrer la librairie filesystem dans mon exécutable. Je compile avec gcc 3.4.2 de MinGW avec le makefile suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

EXEC = test IPATHS = -IC:\Developpement\boost_1_39_0 LPATHS = -LC:\Developpement\boost_1_39_0\stage\lib LFLAGS = -lboost_filesystem-mgw34 -lboost_system-mgw34   $(EXEC): main.o g++ -static $(LPATHS) $^ $(LFLAGS)   main.o: main.cpp g++ $(IPATHS) -c $^

---

Mais j'utilise mal l'option -static apparemment puisque j'ai toujours besoin des dlls. J'espère que vous pourrez 'aider à trouver mon erreur. Merci.

Salut,

Le fait est que boost::filesystem est une bibliothèque qui n'existe qu'en version dynamique :aie:

La seule solution potentielle que je puisse envisager (et je t'avoue qu'elle "m'effraie" quelque peu tant elle est peu orthodoxe (re :aie:) ), ce serait d'introduire directement l'ensemble des en-tête et des fichiers d'implémentation de cette bibliothèque dans ton projet, en veillant à ce que la macro BOOST_FILESYSTEM_DECL (qui défini selon le cas __declspec(dllimport) ou __declspec(dllexport) ) soit définie à ... rien du tout...

Salut,

Citation:

---

Envoyé par koala01

Le fait est que boost::filesystem est une bibliothèque qui n'existe qu'en version dynamique

---

Pas que je sache non (en tous cas j'ai des versions statiques sous cygwin et macos).

MAT.

Ah mince, c'est le cas spécial de filesystem ou de plusieurs autres? Je vais rester avec les dll du coup, sinon trop d'efforts pour pas grand chose.

C'était le cas il y a longtemps mais depuis au moins quelques années toutes les bibliothèques peuvent être liées statiquement sur toutes les plates-formes, à ce que je sache...

MAT.

Peut être qu'il faut que je recompile filesystem avec l'option link=static de bjam:

Citation:

---

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.

---

Je vais tenter ça.

2ème hypothèse: j'ai linké avec une librairie sans suffixe du type "sd" ou "mt". En fait il doit y avoir des versions statiques, multithread...etc

Je vais tester avec les sd en supposant que le "s" veuille dire static.

Citation:

---

Envoyé par Mat007

Salut,


Pas que je sache non (en tous cas j'ai des versions statiques sous cygwin et macos).

MAT.

---

Effectivement, lorsque tu utilise cygwin, tu es dans un environnement posix, mais, d'après le config.hpp propre à filesystem, il semble que tout soit fait pour que si tu travailles sous environnement windows réel, la bibliothèque soit créée sous la forme d'une dll :aie:

Le fait est que la gestion du système de fichier est alors déléguée à l'API windows, qui fait elle-même appel à plusieurs dll...

Ceci expliquant cela ;)

Citation:

---

Envoyé par Nykoo

Ah mince, c'est le cas spécial de filesystem ou de plusieurs autres? Je vais rester avec les dll du coup, sinon trop d'efforts pour pas grand chose.

---

A ma connaissance, mais sous réserve de vérification, il y a trois ou quatre bibliothèques dans le cas ;)

Citation:

---

Envoyé par Mat007

C'était le cas il y a longtemps mais depuis au moins quelques années toutes les bibliothèques peuvent être liées statiquement sur toutes les plates-formes, à ce que je sache...

MAT.

---

Disons que, par défaut, elles restent générées sous la forme de dll...

Maintenant, il n'est pas exclu qu'elles aient évolué pour pouvoir être dénérées sous forme de bibliothèque statique :D

Mais il faut sans doute alors le demander explicitement :aie:

Bon ça marche avec les librairies avec le suffixe "s" (boost_filesystem-mgw34-s.lib et boost_system-mgw34-s.lib). C'est bien linké en static plus besoin de dll.

J'ai compilé filesystem avec bjam sans spécifier l'option link, donc il m'a sorti toutes les versions possible des librairies, soit une 20aine par librairie :aie:

Par contre c'est la merde parce que les librairies se finissent en ".lib" et ne sont pas toutes précédées de "lib". Donc le linker avec l'option -lfilesystem va me chercher libfilesystem.a et ne les trouve pas c'est logique. J'ai donc dû renommer les librairies c'est pas très propre.

Citation:

---

Envoyé par Nykoo

Par contre c'est la (...) parce que les librairies se finissent en ".lib" et ne sont pas toutes précédées de "lib". Donc le linker avec l'option -lfilesystem va me chercher libfilesystem.a et ne les trouve pas c'est logique. J'ai donc dû renommer les librairies c'est pas très propre.

---

Quelle version de bjam tu as utilisée ?
Je sais que sous cygwin il faut le recompiler et non utiliser la version binaire x86 fournie, sinon ça fait exactement ce que tu décris : ça crée des .lib et au lieu des .a

MAT.

bjam me dis:

Citation:

---

Boost.Build V2 (Milestone 12)
Boost.Jam 03.1.17

---

La dernière release de sourceforge version ntx86, donnée en lien à partir de http://www.boost.org/users/download/

J'ai compilé avec:

Code:

---

bjam --build-dir=build toolset=gcc --build-type=complete

---

Ok donc tu peux essayer en recompilant bjam, ce qui se fait depuis la racine de boost avec :

Code:

---

1 2 3

cd tools/jam/src/ ./build.sh cd ../../..

---

Et ensuite pour compiler boost :

Code:

---

tools/jam/src/bin.cygwinx86/bjam.exe (etc..)

---

MAT.

J'ai essayé avec le buil.bat (je suis sous Xp), mais j'ai toujours des *.lib M'emfin c'est pas un gros problème je trouverai peut être la solution plus tard par hasard.

Ok, peut-être que ce n'est valable que pour cygwin...

MAT.