Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
En pratique : Utilisation du compilateur GCC sur AmigaOS 68k (deuxième partie)
(Article écrit par Mathias Parnaudeau et extrait de GuruMed.net - janvier 2003)
|
|
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 des fichiers d'en-tête notamment).
Think different
Chaque compilateur présente ses particularités, par exemple SAS/C possède un fichier d'en-tête
nommé "dos.h" (en plus d'un 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 paquets 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 appel 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 alertes,
de comprendre le comportement du compilateur ou encore de ne pas dupliquer les fichiers d'en-tête
pour chaque nouveau compilateur.
Si vous avez installé StormC (pour son ensemble éditeur, débogueur, gestionnaire de projets) suite
à l'achat du CD Amiga 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 fichiers d'en-tête, qu'on sépare ainsi :
- gg:m68k-amigaos/include (les versions GCC de proto/, inline/, etc.).
- gg:os-include (fichiers d'en-tête du NDK, indépendante du compilateur : retirer les pragmas et protos).
- gg:include (fichiers d'en-tête standards de GCC).
- gg:local/os-include (non standard, pour un usage particulier, l'ajout de nouveaux paquets).
Ainsi, le répertoire des fichiers d'en-tête 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. Ça 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 pluricompilateurs, revenons à celui qui nous concerne pour l'instant.
GCC provient du monde Unix, aussi il faut parfois quelques accommodations pour AmigaOS. Comme il utilise
par défaut des notions Unix, il joindra automatiquement la bibliothèque ixemul : il s'agit d'une bibliothèque
d'émulation des bibliothèques standards 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 bibliothèques
ANSI, il n'en est 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 lien :
En liant ainsi, vous bénéficiez de l'ouverture automatique des bibliothèques système. Si vous souhaitez
garder ce petit confort en utilisant ixemul, ajoutez alors l'option "-lauto" au lien.
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 bouchons ("stubs") pour toutes les
fonctions du système d'exploitation 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 texte 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 sensible à la casse dans les fichiers d'en-tête, 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 !
Ça pourrait en devenir décourageant. Après quelques explications...
Avec MUI, des ennuis peuvent apparaître, tout d'abord parce qu'il définit des macros dans un format que
ne reconnaît pas forcément GCC, suivant les fichiers inlines utilisés. 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.
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 à l'édition de liens et génère du code pour toutes les
variantes d'Amiga (68k, WarpOS, PowerUp, MorphOS).
|
