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

[koala01]

Pour information (au cas où tu voudrais essayer de compiler Gcc 4.9 depuis le svn): il y a un problème avec un pragma (pargma target("sse4.2") pour ne pas le citer) depuis la revision 200349 sur svn (voir le bugtracker)

Je viens de parler avec kai (l'un des dev de mingw-w64) qui m'a confirmé qu'il avait une idée du problème, mais qui a énormément de choses à faire dans son pipe...

Il s'y intéressera d'avantage dés qu'il aura un peu de temps

Mais bon, il est comme tout le monde et n'a qu'une tête et deux mains, le pauvre

[camboui]

Requête à ceux qui vont se lancer, pourriez-vous publier le shell batch/script qui fait le tout de A à Z ?
Merci

[koala01]

Je le fais généralement en ligne de commande...
Mais tu peux trouver un certains nombre de scripts (en fait, tous les scripts requis pour compiler l'ensemble ) sur github merci (ruben )

[minnesota]

Merci encore koala01 pour les informations complémentaires... et justement pour éviter le genre de désagréments causés par les snapshots, j'ai pris pour habitude de ne travailler qu'avec des releases. Sinon je rappelle juste que mon intention est de produire une distribution 100% 32 bits pour un environnement 32 bits...

[koala01]

Merci encore koala01 pour les informations complémentaires... et justement pour éviter le genre de désagréments causés par les snapshots, j'ai pris pour habitude de ne travailler qu'avec des releases.

Voilà une décision bien sage

Sinon je rappelle juste que mon intention est de produire une distribution 100% 32 bits pour un environnement 32 bits...

Oupps... au temps pour moi

Bah, en gros, la seule différence consiste, à peu de choses près, à passer l'option build=x86-w64-mingw32 au lieu de build=x86_64-w64-mingw32 et l'option --disable-werror au lieu de l'option --disable-bootstrap

Pour le reste, c'est sensiblement pareil.

NOTA: concernant binutils, il me semble malgré tout intéressant de le compiler une deuxième fois avec la version de Gcc que tu viens de créer, ne serait-ce que pour être sur

[minnesota]

NOTA: concernant binutils, il me semble malgré tout intéressant de le compiler une deuxième fois avec la version de Gcc que tu viens de créer, ne serait-ce que pour être sur

Ça marche je prépare déjà le terrain...

[minnesota]

Salut

voilà, j'ai commencé la compilation pour binutils, c'est en cours, j'ai juste un souci avec libiberty qui me génère un trojan faux positif lors des tests gettimeofday...

[minnesota]

Voilà mon retour

Bon, finalement, je me suis attelé à faire une fabrique de "librairies", spécialement dédié à ça, c'est en cours de peaufinage...

Le "compilateur", pour l'instant, c'est celui de tdm (4.7.1), la version MinGW 32-bit, et tout comme le 4.6 de mon environnement de dev gcc, c'est le seul qui n'a pas été capricieux au premier test. Les versions 32 bits à base de mingw-w64 n'ont pas fonctionné, y compris celle de Ruben, j'ai pas eu l'occasion d'approfondir la question ou de rechercher pourquoi, alors je me suis contenté de celle précédemment citée en attendant. Pour info, la plateforme est un Windows XP 32bits tournant sur Pentium 4 Northwood, tout code produit doit au minimum être compatible avec et il doit pouvoir être testé et fonctionner dans cet environnement.

Pour MSYS, j'ai pris la version distribuée par mingw64... le seul souci c'est que les points de montage semblent capricieux, ça ne fonctionne pas toujours, y compris sur la ligne de commande alors que les instructions tapées sont les mêmes... c'est en cours de consolidation...

Enfin, binutils... c'est "compilé", sauf que j'ai dû enlever toute "référence" à gettimeofday dans le script configure pour empêcher le blocage des binaires de test "conftest.exe" par l'antivirus... il faudra que je regarde à modifier le code source de test, car il faut que ça fonctionne sans avoir à configurer ou désactiver l'antivirus...

checking for ffs... no
checking for getcwd... yes
checking for gettimeofday... rm: cannot remove `conftest.exe': Permission denied
yes
checking for index... rm: cannot remove `conftest.exe': Permission denied
rm: cannot remove `conftest.exe': Permission denied
no
checking for insque... rm: cannot remove `conftest.exe': Permission denied
rm: cannot remove `conftest.exe': Permission denied
no
checking for memchr... rm: cannot remove `conftest.exe': Permission denied
rm: cannot remove `conftest.exe': Permission denied
no

Une fois que tout ça sera stabilisé, je passerai à la suite...

[minnesota]

voilà où j'en suis après une première refonte:

le système de chargement de l'environnement fonctionne bien, y'a juste les variables "homepath" et "homedrive" qui font des siennes, ça semble inhérent à msysCORE, voici les fichiers sources y faisant référence:

http://mingw.cvs.sourceforge.net/vie...cc?view=markup
http://mingw.cvs.sourceforge.net/vie...cc?view=markup

"homedrive" pointe toujours vers le volume système alors que tous les profils utilisateur de ce Windows XP sont dans un volume différent et dans un chemin sans espace.
"homepath" vaut au mieux "/", au pire, il pointe sur le dossier système.

Une recherche m'a montré que le problème a déjà été évoqué en 2009, mais ça ne semble pas avoir bougé, et je ne peux pas me disperser à tenter de faire un patch alors que je me suis déjà éloigné de mon objectif initial de NTGCC à NTLibMaker, mais c'est pour la bonne cause puisque l'un permettra de faire l'autre et bien plus.

Pour "home", la variable qui représente le dossier et le profil utilisateur, pas de problème, j'ai cependant préféré la localiser dans la fabrique plutôt qu'utiliser le profil utilisateur Windows, je sais pas si c'est une bonne idée (?), d'ailleurs je me demande si je ne devrais utiliser un seul profil pour tous les utilisateurs ???

Quand "home" est défini, normalement les deux autres ("homepath" et "homedrive") ne sont pas utilisés du coup c'est pas critique.

Si le besoin de se configurer un "shell" au petit oignon se fait sentir, sachez qu'il est possible d'utiliser les fichiers d'initialisation système (msys\etc\profile) ou local, comprendre "utilisateur" (%home%\.profile), à cet effet et à condition d'appeler l'interpréteur "sh" avec le paramètre "--login". L'interpréteur "bash" est beaucoup plus flexible de ce côté, mais mieux vaut rester sur le standard "posix" avec "sh" car tous les scripts des Lib requièrent en général "sh" (ils commencent par "#!/bin/sh"). Pour la petite histoire, en fait c'est les mêmes binaires, mais en interne, suivant la ligne de commande et donc le "shell" invoqué, le fonctionnement est différent, ici "sh" n'est autre que la restriction de "bash" à la conformité "posix" (bash --posix).

pour un aperçu des commandes prises en charge, cf. les manuels :

http://linux.die.net/man/1/sh
http://linux.die.net/man/1/bash

Voilà, il me reste à intégrer "package config" et faire un script qui force les points de montages à la volée pour palier aux déficiences (évoquées dans un précédent post) du script "mount" (msys) que je ne me vois pas modifier.

L'étape suivante sera l'introduction de la notion de job (ou task) avec en finale la possibilité de reprise de la construction de la Lib en cas d'échec de celle-ci...

[koala01]

A vrai dire, j'ai toujours utilisé la dernière version stable de msys pour mes compilation (celle que l'installateur que tu trouves ==>ici<== t'installera).

Il en va de même que pour le compilateur (32 bits) "de base", avant que je n'aie une version de gcc en 64 bits.

Es-tu sur d'utiliser msys et non cygwin, car ce dont tu parle me fait furieusement penser à cygwin

Je peaufine un script qui fait tout tout seul (téléchargement des source, configuration, compilation et installation des prérequis, de binutils, de gcc et des outils tierces intéressant).

Quand je serai sur qu'il est au point, je vous le présenterai

[minnesota]

merci

J'avais pris celle distribuée par mingw64, c'est la même sauf que tout est dans un package, mais c'est pas la dernière version...

MINGW32_NT-5.1 1.0.17(0.48/3/2) 2011-04-24 23:39 Msys

Suite au constat, j'avais regardé les sources de la version 1.0.18 mais y'avait pas de différences significatives avec la précédente sur le point évoqué, et comme tu m'as fait douté, je viens de faire une mise à jour :

MINGW32_NT-5.1 1.0.18(0.48/3/2) 2012-11-21 22:34 Msys

mais ça n'a rien changé...

Après si je n'étais pas entré dans les détails, effectivement, ça serait passé inaperçu et ça n'aurait peut-être eu jamais d'incidence...

[camboui]

Je peaufine un script qui fait tout tout seul (téléchargement des source, configuration, compilation et installation des prérequis, de binutils, de gcc et des outils tierces intéressant).

Quand je serai sur qu'il est au point, je vous le présenterai

Miam

[koala01]

Allez, pour ceux que cela peut intéresser, le script est (enfin) disponibles sur github : https://github.com/PhDunski/build-mingw-w64

*Normalement*, il ne devrait pas poser de problème majeur et fonctionner avec les différentes versions, aussi bien taguée "release" que "snapshot".

Ne soyez pas trop surpris : ce script crée un fichier log spécifique par étape passée

[minnesota]

Super, merci koala01
ça me sera utile pour les options de compilation

Sinon, moi j'ai préféré faire un script par lib... mais uniquement pour la compilation... tout le reste est géré en externe... d'ailleurs suite à notre dernière discussion et pour changer un petit peu je me suis attaqué à un downloader/updater pour "msys", avec recherche et téléchargement automatique des derniers packages disponibles et plus généralement tout ce qu'on veut sur Sourceforge... le script msys prend forme et fonctionne déjà plutôt bien... j'en suis à l'étape post-téléchargement... après il faudra juste rendre le moteur Sourceforge générique... J'en avais déjà fait un pour SVN et Mingw-w64 parce que Winpthreads n'était pas dispo dans la release...

Le coeur est basé essentiellement sur des scripts cmd, plus deux ou trois outils classiques et maisons... mais je pense que tout ça finira, enfin pas pour l'instant par ce que je veux pas m'éparpiller, sur du python, surtout que je connais pas encore le langage...

Sinon une astuce pour les points de montages sur "msys" et donc ton chemin "/mingw", parce qu’au départ je modifiais dynamiquement le fichier "fstab", je me suis rendu compte qu'un simple montage dans le Shell mettait directement à jour ce fichier, ce qui évite de l'éditer...

Voilà où ça en est en ce qui me concerne