Re: Pb Aranym

Le 10/08/2024 à 14:41, Francois LE COAT a écrit :

Salut,
 OL écrit :

Or j'ai toujours programmé avec des outils à jour.

>
2.95.3 c'est de 2001, donc toujours à jours jusqu'il y a 20 ans, tu as un peu de retard il me semble

>
Tu dis cela parce que tu as lancé `gcc -v` avec mon SDK ATARI. Sans
savoir que les binaires (cc1, cpp etc.) sont à jour, mais pas les
fichiers de config, qui contiennent le numéro de version. Ce qui fait
que les fichiers de configuration contiennent 2.95.3, mais il s'agit
de GNU/GCC 3.3.6, le dernier avant GNU/GCC 4. En fait `gcc -v` donne
un résultat erroné, mais on s'en fout, et ce que tu dis est faux. Le
SDK ATARI GCC 3.3.6 n'est pas très clean, mais il marche très bien !

 Ah non ce n'est pas ce que j'ai fait sinon je n'aurais pas parlé de CC1 et LD, mais on peut revérifier si tu veux, redonnes ton adresse et je revérifie (dans 3 jours je suis absent), j"ai tout jeté mais non , j'ai gcc 3 sur Aranym il indique version 3.3, elle est curieuse ta chanson mais on va vérifier, il n'y a pas de soucis.

 Mon SDK GNU/Linux 3.3.6 se trouve à cet endroit :
 <https://eureka.atari.org/gcc3.3.6SDK.zip>

Bon effectivement CC1 est bien en version 3.3, le reste est du 2.8.1, j'ai du interférer avec ma config sous Aranym, il n'a pas du aller cherche le bon CC1.
Cela ne fait pas très unix, des ttp de partout en 2.8.1, je ne comprend pas bien la raison de ce mélange, la seule que je vois c'est que tu veuille compiler sous TOS ou sans environnement unix soit à la main à coup de ttp soit avec un shell comme mon vieux truc (que j'utilise encore parfois) gccshell, mais vu que tu déclares l'environnement dans mint.cnf, un makefile et tu peux utiliser le vrai SDK GCC 3. L'autre possibilité c'est de pouvoir utiliser ld en version 2.8.1 pour pouvoir utiliser de très vieilles libs au format olb mais là c'est en .a donc pas si vieux que cela et qui plus est semble dater de GCC 3.3 si on regarde la date. Le ld date de 1997 et j'ai linké avec ton ld et surprise pour moi cela marche, au départ pour moi connaissait pas à cette époque les .a de toute évidence il le peut. Alors là je ne comprend pas ton explication ci dessous.

 Certes, j'ai gardé l'édition de lien avec les anciennes bibliothèques.
Mais dans les nouvelles bibliothèques, il y a des éléments qui me sont
indispensables, qui ont été supprimés. Tout est très à jour. J'ai pu
aussi bien compiler Eurêka 2.12, que POV-Ray 3.1g, ou MPEG2Decode,
entre autres.

Les libs semblent dater de gcc 3.3, tu es sur si tu utilisait le package standard avec ces libs cela ne fonctionnerait pas ? Je ne vois pas pourquoi cela n'irait pas.

 Il y a certainement beaucoup d'anciennes applications ATARI développées
avec PURE C 1.1, qui pourraient être compilées simplement avec ce SDK.

Bah pardi et puis passer de PureC à GCC en général ce n'est pas le plus dur, je compile aussi bien MyAES en PureC et en GCC morderne à part quelques définitions d'appel systèmes qui peuvent être différents et quelques définitions que l'on doit adapter d'un compilateur à un autre en général cela se passe assez bien, il y a toujours le contre exemple il faut débugguer un peu, mais aujourd,hui je programme des mois en PureC et généralement passer à GCC marche du premier coup, quelques warnings en plus que j'essaye de fixer. Le plus gros tracas en fait ce sont les appels GEM, alors j'ai réglé le problème une bonne fois pour tout, j'ai jeté la libs de PureC pour remplacer par gemlib, quand c'est pas adapté cela peut prendre du temps à adapter faut au moins définir le mot clef pour avoir les noms anciens sinon c'est beaucoup de travail. Après faut voir si cela fonctionne et debugguer si besoin.

J'ai testé GNU/GCC 4, et rien ne fonctionne plus comme avant avec GCC 3.

Pour GCC 4 mintlib n'est plus compatible avec -mshort il me semble (ou tout au moins pas en entier), on peut peut être essayer de recompiler la mintlib de GCC 3, mais il y aura des noms en doublons car GCC 4 ajoute des fonctions internes qui n'ont plus lieu d'être dans la lib du coup. On ne peut pas récupérer les anciennes libs car des changements importants ont eu lieu dans GCC4 pour la performance entre autre sur les structures afin d'assurer l'alignement
Par exemple struct foo [
unsigned char R;
unsigned char G;
unsigned char B;
}
par défaut ne fera plus 3 octets mais 4 pour l'alignement sur 32 bits, ce qui peut être embêtant si on veut l'utiliser sur une image 24 bits par exemple, on peut s'en sortir avec un pragma ou un attibute sur la structure. Une autre solution c'est d'utiliser l'option pour les structures compactes mais à ce moment toutes les librairies doivent être compilées avec cette option, à ce moment là le GCC se comportera plus comme GCC 3, pas dit que cela soit suffisant. Bien sur si une lib a une convention et le compilateur en a une autre cela ne peut pas fonctionner correctement.

J'ai espéré un temps que AHCC devienne compatible, mais Henk Robbers
n'est plus sur le WEB, depuis quelques temps. Les ATARIstes ont eu
longtemps le choix parmi les compilateurs compatibles, plus aujourd'hui.
 La situation est vraiment préoccupante pour les développements ATARI.

Elle n'est pas préoccupante, gcc fonctionne bien mais cela demande un peu d'effort c'est sur pour s'adapter, il  a un principal défaut c'est d'être très lourd, compiler avec cela sur un environnement Atari, c'est super lourd dingue même sous Aranym, faut passer au cross compilation pour bien faire mais j'avoue au bout d'un moment c'est pénible, alors PureC continue de bien fonctionner et c'est ce que j'utilise et de temps en temps je compile avec GCC, en suivant quelques principes simple une fois le premier effort fait il y a très peu de mauvaises surprises, deux compilateur c'est bien pour trouver des bugs.
OL