Discussion :

[minnesota]

Salut tout le monde,

Comme j'en ai effleuré l'idée il y a quelque temps, je passe à la réalisation et je vais faire une compilation "publique" de mingw-w32 (mingw64) et gcc 4.8.1 (la dernière release à cet instant) pour Windows 32bits, avec prise en charge de C et C++11 uniquement (?), un gestionnaire d'exceptions setjmp/longjmp, et activation de std threads si ça vous semble judicieux (?), sinon rester sur win32 threads sachant que ça n'empêche pas d'utiliser pthread ou Boost.Thread, quid de OpenMP, pour qui le souhaite.

Outre les requis mpc, gmp, mpfr et bien sur binutils, gcc, mingw-w64, est-ce que vous voyez d'autres Lib dont l'intégration serait d'une utilité avérée ?

De mêmes qu'elles seraient selon vous les options indispensables et qu'il faut activer ?

Voilà, le mot d'ordre c'est flexibilité... la distribution s'appellera "ntgcc32"... et sera une des composantes essentielles de "ntflexEDI" si ça parle à certains ...

Merci.

[koala01]

Salut,

J'ai envie de dire "casses toi pas la tête" : entre TDM et le projet Mingw-w64 (fork de mingw), tout est déjà fait

Sinon, pour les options (ad minima):
binutils :

1. --enable-auto-import
2. --disable-nls

gcc (*):

• build=x86_64-w64-mingw32
• --prefix=
• --sysroot=
• --enable-static
• --enable-shared
• --enable-languages=
• --enable-libstdcxx-time
• --enable-threads=posix (indispensable si tu veux disposer de std::thread, pour la 4.8.1 et avant en tout cas)
• --enable-libstdcxx-thread
• --enable-libgomp
• --enable-lto
• --enable-graphite
• --enable-fully-dynamic-string
• --enable-version-specific-runtime-libs
• --disable-win32-regostry
• --disable-werror
• --with-gmp=
• --with-mpfr=
• --wit-mpc=
• --with-isl=
• --with-cloog=
• --enable-cloog-backend=isl

(*) les option suivies d'un = attendent quelque chose : un chemin ou une autre information
Les prérequis (gcc):

• gmp
• mpfr
• mpc
• isl
• cloog

les outils "indispensables"

• gdb
• make

les bibliothèque tierces utiles:

• iconv
• icu
• libxml2
• openssl
• (mman)

la suite:

• boost
• Qt
• ...

NOTA:
- mingw-w64 arrive dans le "rush final" avant la version 3, j'ai observé pas mal d'activité sur le svn ces derniers temps (le dernier remonte à une demi heure au moment d'écrire ces lignes)... Il serait peut etre sage d'attendre quelques jours avant de te lancer dans l'aventure

- il est préférable d'utiliser winpthreads plutôt que pthreads, disponible sur le site de mingw-w64, mais tu devras veiller à le compiler séparément pour la version 32 et 64 bits

Voilà, en gros, mon opinion (pour info, j'ai perso déjà une version de Gcc-4.8.1 avec au moins tout cela depuis plusieurs mois (depuis la release officielle, en fait)

[koala01]

Ah, au fait, lors de la compilation de boost, il faut utiliser l'option pch=off, autrement la compilation de boost::math (entre autres) échoue suite à un nombre trop important de récursivité template

[Caramorgar]

À moins que tu as des options de compilation particulière, t'embête pas trop. Ca fait des années que equation.com propose une version de gcc compilé pour Windows : http://www.equation.com/servlet/equation.cmd?fa=fortran
Tu as même les versions en cours de dev (gcc 4.9)

[minnesota]

Je savais que tu serais le premier à répondre koala01, je te connais trop bien ton expérience sur le sujet me sera d'un grand soutien...

Et merci beaucoup à tous les deux pour vos premières réponses

En fait, j'aimerais bien le faire au moins une fois, même si par la suite une version toute faite sera utilisée, car je ne suis pas encore certain d'être en mesure d'assurer la maintenabilité de cette partie.

Aussi, je me rends compte que je me suis mal exprimé, dans les Lib utiles, voire indispensables à intégrer, je pensais plus à des "composantes" dans le genre de ppl et cloog pour l'option graphite, le genre de chose qu'on décide avant ou à la compilation de gcc et qu'on ne peut plus facilement intégrer par la suite contrairement à Boost par exemple, qui évidemment n'entre pas dans ce cas. Le but, c'est de faire une distribution de taille légère au possible, mais suffisamment complète pour ne pas avoir à la recompiler suite à l'omission d'une fonctionnalité importante. Quant à l'enrichissement par des Lib ou frameworks tiers, ça se fera selon les besoins de chacun, du on demand.

Si vous avez un avis tranché sur le modèle de threads à adopter, n'hésitez pas à en faire part, notamment si vous avez rencontré des conflits ou incompatibilités. Jusqu'ici je n'ai utilisé que win32, donc je n'ai aucun recul de ce côté là.

Pour l'attente de la version 3, message recu

Merci.

[koala01]

En fait, j'aimerais bien le faire au moins une fois, même si par la suite une version toute faite sera utilisée, car je ne suis pas encore certain d'être en mesure d'assurer la maintenabilité de cette partie.

Disons que c'est une expérience intéressante à faire

Aussi, je me rends compte que je me suis mal exprimé, dans les Lib utiles, voire indispensables à intégrer, je pensais plus à des "composantes" dans le genre de ppl et cloog pour l'option graphite, le genre de chose qu'on décide avant ou à la compilation de gcc et qu'on ne peut plus facilement intégrer par la suite contrairement à Boost par exemple, qui évidemment n'entre pas dans ce cas.

Les trois bibliothèques "minimum" pour pouvoir compiler Gcc sont gmp, mpfr et mpc.

Pour autant que j'ai bien compris le principe, isl et cloog sont essentiellement là pour permettre une meilleure optimisation du compilateur lui-même (mais cela reste malgré tout à confirmer )

Le but, c'est de faire une distribution de taille légère au possible, mais suffisamment complète pour ne pas avoir à la recompiler suite à l'omission d'une fonctionnalité importante. Quant à l'enrichissement par des Lib ou frameworks tiers, ça se fera selon les besoins de chacun, du on demand.

dans ce cas, gmp, mpfr et mpc sont, très certainement, requises.

Les options --enable-libgomp --enable-libssp et --enable-lto sont très certainement utiles

Aussi, si vous avez un avis tranché sur le modèle de threads à adopter, n'hésitez pas à en faire part, notamment si vous avez rencontré des conflits ou incompatibilités. Jusqu'ici je n'ai utilisé que win32, donc je n'ai aucun recul de ce côté là.

Pour la version 4.8.1 (et précédentes), si tu veux pouvoir activer le support de std::thread, tu n'as pas le choix : il faut passer par les threads posix (et donc par pthread ou de préférence winpthread ).

Il faut la compiler après la crt, mais avant la libgcc elle-même

Nota: si tu pars d'un compilateur 32 bits (mingw autrement dit), il faudra travailler en plusieurs fois si tu veux une version 64 bits capable de compiler en multilib (autrement, certains outils -- ceux fournis par binutils en particulier -- seront toujours en version 32 bits, ce qui pose problème lorsqu'il s'agit, par exemple de compiler Qt ).

L'ordre "logique" pour travailler est le suivant:
première passe

1. compiler binutils une première fois, avec les options --build=x86_64-w64-mingw32 ( --enable-auto-import --disable-nls)
2. compiler successivement gmp, mpfr, mpc (attention: par défaut, gmp compile avec --enable-static --disable-shared, et mpc essaye de faire le contraire... il faut donc passer l'option --disable-shared --enable-static pour compiler mpc ), isl et cloog
3. installer les en-tête propres à mingw-w64
4. configurer gcc avec l'option --disable-bootstrap (il ne sert à rien de se taper les trois stages si c'est pour tout recommencer par la suite )
5. make all-gcc && make install-gcc pour les frontend
6. compiler la crt mingw-w64
7. compiler winpthread (en 32 et en 64 bits) De préférence dans des dossiers de destination séparés, surtout si tu utilises l'option --enable-shared
8. dans le dossier de compilation de gcc, make all-target-libgcc && make install-target-libgcc
9. il y a une erreur dans le script d'installation qui fait que libgcc_s.a se retrouve dans le mauvais dossier (respectivement <prefix>/lib/gcc/x86_64-w64-mingw32/lib et <prefix>/lib/gcc/x86_64-w64-mingw32/lib32 au lieu de <prefix>/lib/gcc/x86_64-w64-mingw32/<version-gcc> et <prefix>/lib/gcc/x86_64-w64-mingw32/<version-gcc>/32) les copier / déplacer dans le(s) bon(s) dossier
10. dans le dossier gcc toujours : make && make install

Il y a un dernier problème lors de l'installation : les dlls propres à gcc sont toutes placées dans le dossier <prefix>/bin, indépendamment de la version (32 bits ou 64 bits) pour laquelle elles ont été générées.

La plupart des dlls que l'on retrouve dans ce dossier est en version 64 bits, mais il y en a au moins l'une d'elle qui est en version ... 32bits

Il faut donc chercher les dlls dans le dossier de compilation de gcc et les copier manuellement : l'idéal, selon moi, est de placer la version 64bits dans <prefix>/bin et la version 32bits dans le dossier <prefix>/bin/32 (à créer pour l'occasion ).

Modifier la variable PATH pour prendre les nouveaux dossiers en compte
deuxième passe

• Si cela fonctionne (ca le fait généralement, mais pas forcément toujours ), copier les sources de gmp, de mpfr, de mpc, de isl et de cloog dans le dossier contenant les sources de gcc en supprimant les informations de version, pour que ces bibliothèques soient compilées en même temps que gcc pour les trois stages.
• re configurer et recompiler binutils (pour avoir une version 64 des outils qu'il propose)
• reconfigurer gcc (avec l'option --disable-werror mais sans l'option --disable-bootstrap), le recompiler et le réinstaller avec make && make install
• (aller au cinéma en attendant, tu en as pour à peu près deux à trois heures )
• recopier les dll comme lors de la première passe (au moins pour les dll 64bits)

Amuses toi bien