Utiliser le compilateur GCC (2/2)
Un article de GuruMed.
Sommaire |
Caractéristiques propres à GCC
Par Corto
L'installation du compilateur GCC effectuée, il reste à voir quelles sont ses différences avec les autres et comment en tenir compte. Ceci vous évitera de perdre votre temps dans de nombreuses recherches. Nous avions uniquement évoqué la dernière fois le besoin important en pile (stack) et l'organisation de l'environnement GeekGadgets de GCC (les répertoires d'includes notamment).
Think different
Chaque compilateur présente ses particularités, par exemple SAS/C possède une include nommée dos.h (en plus de qui lui est propre. Mais les différences les plus importantes viennent de la manière dont sont construits et gérés les appels de fonctions (via les inlines ou les pragmas). Pour sa part, GCC utilise les inlines, tout comme VBCC et StormC 4) au contraire de SAS/C qui préfère les pragmas. Avec l'outil fd2pragma, vous pourrez d'ailleurs obtenir les deux types de fichiers à partir de fichiers FD et clib, souvent fournis dans les packages destinés aux développeurs.
Il peut être nécessaire de prendre en compte les différences entre les compilateurs. Ou au moins faut-il comprendre un source écrit dans ce but. Ainsi les inclusions doivent faire appels aux directives de condition du précompilateur. Ces adaptations sont un bon point de départ pour rendre le code indépendant du compilateur :
// A utiliser pour vos programmes MUI #ifdef __GNUC__ #include <inline/muimaster.h> #else #include <clib/muimaster_protos.h> #endif // Adapter des directives propres à SAS/C #ifdef __SASC #define ASM __asm #define SAVEDS __saveds #else #define ASM #define SAVEDS #endif
Tout ceci peut vite devenir un casse-tête. Pour clarifier les choses, il semble bon d'envisager l'utilisation d'un environnement multicompilateur : cela permet d'apprendre beaucoup de notions nouvelles, de tester plus sévèrement son code car aucun outil ne laisse passer les mêmes warnings, de comprendre le comportement du compilateur ou encore de ne pas dupliquer les includes pour chaque nouveau compilateur. Si vous avez installé le StormC (pour son ensemble éditeur, débogueur, gestionnaire de projets) suite à l'achat du CD Developer puis GCC après le précédent article, cette préparation vous servira (et que diriez-vous de profiter du gratuit VBCC ?).
GCC semble être le seul à proposer plusieurs répertoires pour contenir les includes, qu'on sépare ainsi :
- gg:m68k-amigaos/include (les versions GCC de proto/, inline/, ...)
- gg:os-include (includes du NDK, indépendante du compilateur : retirer les pragmas et protos)
- gg:include (includes standards de GCC)
- gg:local/os-include (non standard, pour un usage particulier, l'ajout de nouveaux packages)
Ainsi, le répertoire des includes standards (provenant du NDK) d'un autre compilateur peut pointer sur gg:os-include : ils partageront ainsi la même ressource. Pour GCC, vous pouvez effacer tous les fichiers d'icônes et ceux des répertoires pragma, pragmas et proto de ce répertoire car GCC ne semble pas les utiliser, au profit de ses propres fichiers qu'il fournit. Par contre, si vous utilisez un autre compilateur en plus, il faudra déplacer ces répertoires à un endroit qui lui est propre.
Pour rebondir sur les inclusions de fichiers spécifiques décrites plus haut, et afin de les concilier, on emploiera de préférence les fichiers de type proto qui font appel aux fichiers inline ou pragma suivant le compilateur. Il peut être conseillé d'inclure uniquement le proto dans les programmes qui pourront aisément être recompilés avec d'autres compilateurs que le vôtre. Ca permet aussi d'alléger le code en le déplaçant dans les fichiers de proto.
Just do it
Après cette évocation d'une solution pluri-compilateurs, revenons à celui qui nous concerne pour l'instant. GCC provient du monde UNIX, aussi il faut parfois quelques accomodations pour l'AmigaOS. Comme il utilise par défaut des notions UNIX, il joindra automatiquement la librairie ixemul : il s'agit d'une librairie d'émulation des librairies standard d'UNIX. Elle permet de recompiler (généralement simplement) des applications UNIX pour qu'elles fonctionnent sous AmigaOS, car bien qu'il utilise les librairies ANSI, il n'en ait pas pour autant conforme POSIX. Sans ixemul, il faudrait récrire une partie du programme.
Pour des développements AmigaOS, vous n'aurez certainement pas toujours besoin d'utiliser l'ixemul.library. Si tel est le cas, ajouter l'option "-noixemul" au moment du linkage :
- gcc -noixemul
En liant ainsi, vous bénéficiez de l'ouverture automatique des librairies système. Si vous souhaitez garder ce petit confort en utilisant ixemul, ajoutez alors l'option "-lauto" au linkage.
- gcc -lauto
Important : utilisez toujours la ligne de compilation dans cet ordre, ça peut complètement influencer le résultat !
L'amiga.lib
Vous pourrez aussi avoir besoin de la joindre à votre projet. Elle contient des fonctions diverses facilitant la programmation système. Implémentée différemment selon le compilateur, l'amiga.lib doit en théorie contenir les mêmes fonctions (quitte à ne pas être implémentées de la même façon). Elle peut elle-aussi avoir des spécificités : l'amiga.lib de VBCC contient les stubs pour toutes les fonctions de l'OS qui appellent automatiquement Run68k() avec les paramètres appropriés. Elle procède à un enrobage des appels système, une bibliothèque possédant une adresse de base, par rapport à laquelle se réfère les adresses relatives des fonctions.
A propos de l'édition de liens, sachez que les formats d'objets de GCC lui sont propres. Il est donc impossible de lier directement des objets (fichiers .o) générés par SAS/C et par GCC. Remarque : il semble que VBCC s'accommode aisément de presque tous les types de formats.
Un dernier mot concernant la compilation : si vous utilisez, et je vous le conseille, les fichiers makefile, sachez que GCC demande absolument une tabulation à la ligne suivant la cible. Si vous utilisez un éditeur de textes qui remplace les tabulations par des espaces, ça ne fonctionnera pas (voir messages d'erreur). Souvenez-vous donc que le Workbench propose un Emacs rudimentaire mais suffisant pour ce travail. GCC est case sensitive dans les includes, pas comme certains compilateurs permissifs qui se vendent pourtant très bien. Il n'accepte pas les noms de variables ou de fonctions contenant des accents (oui, j'avais osé ! ;-)
MUI sans douleur
Beaucoup ont eu autant de problèmes pour installer GCC que pour utiliser MUI avec lui ! Ca pourrait en devenir décourageant. Après quelques explications, ...
Avec MUI des ennuis peuvent apparaître, tout d'abord parcequ'il définit des macros dans un format que ne reconnaît pas forcément GCC, suivant les inlines utilisées.
Si on génère ces fichiers avec l'outil fd2pragma dans son mode 41 ("old style"), les problèmes sont résolus. Si la conversion a lieu en mode "new style", le message d'erreur "unterminated macro call" devrait apparaître à la compilation. Ceci est apparemment causé par les règles d'indentation des fichiers de développement de MUI.
Dans ce cas il faut ajouter un End à chaque appel qui crée un objet, ce qui n'a rien à voir avec les macros Child ou WindowContents. Des objets comme HGroup, VGroup, WindowObject, RectangleObject sont toutes terminées par un End. Mettre une macro Child ou WindowContents devant et sur la même ligne semble être bon mais cela corrompt en fait le code. Le End correspond au Child alors qu'en fait il est destiné à l'objet à la droite de Child.
Vous pouvez toujours me contacter pour ce genre de problèmes, je constitue une compilation d'erreurs/solutions sur ce sujet.
La compilation de programmes avec GCC ne devrait donc plus poser de problèmes. Il reste encore à profiter des outils de développement annexes qui permettent de gagner du temps dans la réorganisation du code, dans le débogage ou l'optimisation.
Si vous programmez en C uniquement, VBCC pourrait bien vous plaire, c'est le compilateur qui monte : il est gratuit, accepte de nombreux formats au linkage et génère du code pour toutes les variantes d'Amiga (68k, WarpOS, PowerUp, MorphOS).
Si vous rencontrez des erreurs ou si vous êtes face à des incompréhension devant votre compilateur (GCC, VBCC, StormC), faites nous parvenir votre question et nous tenterons d'y répondre.
