Compilation de GCC 4 sous Windows

Configure crée le Makefile dans le dossier courant, mais nous ne voulons pas détraquer le dossier de sources.

En effet, il pourra encore servir un peu après, ne fût-ce que pour vérifier que GCC a bien été compilé.

Tout simplement l'outil que nous utilisons : configure.

Il va créer le makefile et d'autres fichiers d'entête spécifiques à la machine / OS / …

Ceci indique que les outils iront s'installer dans le répertoire /gcc, où se logera la future installation de la dernière version de GCC, avec les bibliothèques et les outils qu'il requiert.

On peut l'appeler la racine de l'installation : cela correspond à l'analogie entre des répertoires et un arbre, vu que l'on parle de l'arborescence des dossiers. Ce répertoire renvoie aux racines de l'arbre, et les dossiers qui y seront créés aux branches.

La plateforme pour laquelle les binutils seront compilés.
i386 correspond au processeur : à partir de la génération Intel 80386 pour les i386, par exemple. Tout Windows est compilé pour ces processeurs, c'est-à-dire que vous pourrez installer Vista sur un bon vieux 80386 (le lancer serait une gageure, mais ceci est un tout autre débat…).
pc : vous êtes installé face à un PC, il me semble ? Même si vous utilisez Boot Camp sur votre Mac, il vous faudra préciser le pc, vu que Windows est prévu pour des PC, à l'origine.
mingw32 désigne le système d'exploitation.

Cependant, vu la multiplicité des compilateurs sous Windows (GCC/MinGW, GCC/Cygwin, GCC/DJGPP, Microsoft C++, Intel C/C++, Borland C++, Digital Mars, LCC, Turbo C/C++…), on préfère le compilateur afin de désigner cet OS, même si seul GCC est capable de le compiler (à cause de ses trop nombreuses extensions non standard ni standardisées).

Il n'est pas très utile de mettre une valeur ici : quel intérêt de devoir appeler qsdsdgezzrth-ld au lieu de ld ? Sauf, bien entendu, si vous souhaitez utiliser plusieurs versions de GCC en même temps, ou d'autres programmes qui utilisent les mêmes noms pour leurs exécutables.

Tous les répertoires où le compilateur devra aller chercher les bibliothèques (fichiers .a), séparés par des :, même si le shell contient déjà une liste de répertoires où chercher les bibliothèques à lier.

Ces quelques répertoires renferment les entêtes de MinGW (nécessaires pour compiler sous Windows), et les entêtes système (comme le noyau Linux).

Nous utiliserons des compilateurs GNU, de la famille GCC, pour compiler ces fameux outils, aidés d'un assembleur et d'un linker gnu.

À noter, aussi, --with-as et --with-ld, qui permettent de préciser quels assembleur et linker précisément il faudra utiliser.
D'habitude, on les recherche dans le path, que nous avons précédemment configuré.

Ces deux paramètres n'ont d'importance que quand on travaille sous HP-PA 1.0, 1.1 et Solaris 2. Sous ces systèmes, on est obligé d'utiliser les deux paramètres conjointement.

Ces options ont la (mauvaise) réputation de casser toute tentative de compilation statique, sous Windows, lorsque l'on utilise ces outils ou des bibliothèques qu'ils ont produits.

Ceci permet de vous éviter de nombreuses recherches futures pour résoudre un problème qui n'aurait pas dû exister.

Une simple séparation de la ligne en plusieurs lignes, vous pouvez passer ce symbole, mais, une fois entré, vous devez faire un retour chariot.

Il est l'équivalent du ^ sous DOS, mais sans « Plus ? » ni « More? » à la ligne suivante.

Normalement, tout devrait se passer sans problème. Si, cependant, on vous dit que GCC est introuvable, qu'il est incapable de produire des exécutables, ou autre chose, vérifiez qu'il est bien dans le path, en l'ajoutant à nouveau dedans :

path=$PATH:/mingw/bin

Quand tout le charabia a fini de se dérouler, normalement, le dossier /work/build/binutils devrait être un peu plus rempli… Lançons donc la vraie compilation…

make all

compile le tout, tandis que

make install

installe le tout, dès qu'il est compilé.

Comme d'habitude, mais ne nous réjouissons pas, cela va (trop) vite changer… Vous pouvez, ici, changer le target, pour refléter au mieux votre configuration. Plus vous serez proche, plus la bibliothèque pourra utiliser des scripts adaptés et performants sur votre processeur. i386 : Intel 80386 et compatibles i486 : Intel 80486 et compatibles i586 : Pentium et compatibles i686 : Pentium Pro et compatibles i786 : Pentium 4 et compatibles i886 : le futur Intel 80886 et compatibles core2 : Core 2 et compatibles ia-64 : Intel Itanium, Itanium 2 et compatibles amd-64 : AMD 64 bits et compatibles (comme Core 2) powerpc : PowerPC, toutes variantes et compatibles sparc : SPARC, UltraSPARC, MicroSPARC, SuperSPARC et compatibles m68k : Amiga, Apollo et compatibles

cd /work/build
mkdir gmp
cd gmp
../../src/gmp/configure \
--prefix=/gcc --target=i386-pc-mingw32 \
--with-gnu-as --with-gnu-ld \
--with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe \
--enable-fat
make all
make install

Ce paramètre indique que l'optimisation pour tous les processeurs supportés par l'OS sera activée. Ceci aura pour conséquence de légèrement augmenter la taille de l'exécutable, mais le rendra plus performant sur tous les processeurs. Ceci n'est pas très utile pour GCC : il n'utilise GMP que pour effectuer quelques calculs constants dans votre programme.

cd /work/build
mkdir gcc
cd gcc
../../src/gcc/configure \
--prefix=/gcc --target=i386-pc-mingw32 \
--program-prefix="" --with-as=/mingw/bin/as.exe  \
--with-ld=/mingw/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as \
--enable-threads --disable-nls  \
--enable-languages=c,c++,ada,fortran,objc,treelang \
--disable-win32-registry --disable-shared --without-x \
--enable-interpreter --enable-libstdcxx-debug \
--with-gmp=/gcc --with-mpfr=/gcc --with-gomp

III-H-1-a. Quelques explications ?▲

make CFLAGS='-O' LIBCFLAGS='-O2' LIBCXXFLAGS='-O2 -fno-implicit-templates' LDFLAGS='-s'
make install

Juste pour indiquer à make ce qu'il peut admettre, à quel point il doit optimiser, et c'est tout.
Vous pouvez ajouter -j2 si vous disposez de deux unités logiques de calcul (dual-core, carte-mère bi-socket…). Vous pouvez incrémenter ce nombre, mais les performances pourraient en pâtir, si vous prenez beaucoup trop de tâches simultanées !
Faites attention, de nombreuses erreurs peuvent être évitées en ne voulant pas aller trop vite.

--prefix indique où seront rangés les fichiers indépendants de la plateforme (c'est-à-dire compatibles entre tous les OS), tandis que --exec-prefix s'occupe du répertoire des fichiers dépendants de la plateforme.

Souvent, ces deux paramètres ont la même valeur.

Il y a aussi moyen de préciser où chaque type de fichier trouvera sa place :

• --bindir
• --sbindir
• --libexecdir
• --datadir
• --sysconfdir
• --sharedstatedir
• --localstatedir
• --libdir
• --includedir
• --oldincludedir
• --infodir
• --mandir

Un peu d'anglais vous permettra d'associer chaque option à sa signification.

--program-prefix permet d'indiquer ce qu'il faut ajouter avant chaque nom de programme.

--program-suffix permet d'indiquer ce qu'il faut ajouter après chaque nom de programme.

--program-transform-name permet d'indiquer le paramètre qui sera passé à sed, pour la transformation du nom.

--build : votre plateforme (presque toujours « devinée »).

--host, ou la plateforme sur laquelle les exécutables compilés s'exécuteront.

--target, alias la plateforme où les outils seront lancés.

Ces commandes existent sur tous les paquets de compilateurs (principalement GCC et les binutils, mais aussi ceux qui nécessitent des outils spéciaux pour la compilation, comme Qt).

Ils se précisent bizarrement dans la ligne de commande et cela peut varier selon le shell.

Cependant, la manière la plus répandue de faire est de les invoquer ainsi :

configure CC=/bin/gcc

IV-A-4-a. Le compilateur C▲

IV-A-4-b. Le compilateur C++▲

IV-A-4-c. Les anciens binutils▲

IV-A-4-d. M4▲

Utilise l’éditeur de liens gold au lieu de ld, censé être plus rapide, ou le compile.

Il est le produit des recherches d'un employé de Google (tiens donc, il vient se perdre ici aussi ?), Ian Lance Taylor. Cependant, il n'est utilisable que pour les systèmes à base d'ELF, comme GNU/Linux, sur des processeurs x86 ou x86_64.

Demande la compilation de libada dès cette étape, un runtime Ada.

Cette option n'est utile que pour les plateformes qui ne disposent pas déjà d'un compilateur Ada, mais il est préférable de ne l'activer qu'avec la configuration de GCC.

Demande la compilation de libssp, un « résumé » de la bibliothèque standard.

De toute façon, s'il est requis pour la compilation, il sera compilé. Ne vous en inquiétez dons pas trop.

Active la compilation de tous les outils dès le stage 1.

Il est recommandé de mettre ici la valeur all.

Active la compilation du ramasse-miettes dans l'environnement d'exécution GNU du langage Objective C.

Un ramasse-miettes est un nettoyeur de mémoire automatique : un objet n'est plus utilisé et ne le sera plus ? On le supprime !

Active la recompilation du compilateur avec la première compilation du compilateur (qui a suivi ? qu'il se dénonce !).

Obligatoire, sauf pour les cross-compilateurs, où cela est strictement impossible.

Active des portions du Makefile, utiles uniquement pour les mainteneurs du paquet.

Disponible aussi dans de nombreux paquets, mais pas tous !

Active de nouveaux tests lors de la phase la plus délicate de la compilation des compilateurs, la première.

Elle n'est vraiment utile que quand vous ne pouvez pas être sûr de la validité de votre compilateur (très vieux, pas GCC…), auquel cas le résultat de la compilation pourrait être incorrect.

Active l'option -Werror de GCC pour la compilation des stages 2 et supérieurs.

Cette option transforme tous les warnings en errors, pour être sûr d'avoir un résultat aussi parfait que possible.

Permettent de préciser les répertoires où il faut trouver GMP et MPFR, compilés, quand configure ne les trouve pas ou qu'ils sont dans des répertoires anormaux.

GCC s'en sert pour calculer, le plus vite possible, tout ce qui peut déjà l'être : vous voulez une fonction qui multiplie par pi, puis qui divise par une constante ? GCC optimisera cela directement en une simple division avec un float, à l'aide de ces deux bibliothèques.

Active les assert, principalement utiles lors du débogage.

Les assertions sont, en gros, ce que vous pensez qu'il va toujours se passer dans votre code : si votre fonction prend, en paramètre, un pointeur non nul, vous pouvez être sûr que ce pointeur ne sera jamais nul ! C'est pour expliquer cela que les assertions ont été créées. N'hésitez pas à vous documenter sur le sujet.

Active l'interface C++, qui utilise tout ce que le C ne permet pas, comme la surcharge d'opérateurs, qui permet d'utiliser les opérateurs sur des objets GMP, au lieu d'utiliser des fonctions.

Active une optimisation de la multiplication, la transformation de Fourrier rapide.

Construit une bibliothèque compatible avec Berkeley MP, une autre bibliothèque de calcul, made in Berkeley, l'université à qui l'on doit, entre autres, BSD.

Active le support des profilers, qui permettent de détecter les portions de code à optimiser, au détriment des performances pures lors de l'utilisation de ce paramètre.

Demande la création de gros binaires (qui contiennent les versions compilées pour plusieurs architectures : sous MacOS X, pour PowerPC et MacIntel, par exemple).

Active l'utilisation de la bibliothèque readline, pour certains exemples en console.

Autorise la bibliothèque à faire part de ses erreurs sur le flux stderr.

Active les fonctions de conversion entre nombres décimaux à virgule flottante et les autres types.