TIGCC 0.94 SP4 r2 pour Linux/Unix - Page 1

Comme TIGCC 0.95 bêta 1 n'est pas encore tout à fait prête (et le portage *nix encore moins), et comme il y avait quelques bogues dans la version *nix du frontend tigcc, j'ai mis en ligne encore un release 0.94. Ceci est un release bugfix pour le frontend tigcc seulement, tout le reste est resté totalement inchangé. Tout changement majeur devra attendre la version 0.95 Beta 1 r1.

Le nouveau release est disponible sur http://tigcc.ticalc.org/linux/.

0.95b1r1 ça claque comme n° de version

Ce topic est là pour la discussion de la nouvelle release et pour rien d'autre!

Juste à temps...

t'as eu de la chance que kernel_panic se soit fait rediriger vers google sinon il aurait pu poster

Tiens, encore un floodeur...

si tu kick tout le monde y'aura plus personne sur ton topic

Vas-y kicke moi! Ah, que c'est bon de se faire kicke

PS: Ca serait cool que tu fasses des raccourcis de m68k-coff-XXX en m68000-ti-linux-gnu-XXX pour tous les programmes. En effet, le terme m68k pour les programmeurs de scripts veut dire > 68020. Ils traitent a part le 68000. Donc des raccourcis seraient biens (mais c'est pas suffisant pour faire fonctionner ces ';';' de scripts configure. J'y arriverais).

Pourquoi veux-tu qu'il y ait "linux-gnu" dedans ?

est ce que ca prend bcp de place tigcc sous unix ? j'ai un compte de 25meg et ca serait cool si je pouvais l'installer

Euh, dans la version que j'ai sous la main (qui doit être la 0.94) y a 5,5 M de binaires (dont tous les tigcc-tools, ttpack etc.)
4,5 M de docs...
le reste se compte en centaines d'octets, ça fait 11 M au total.

Parce que ca fonctionne sous le systeme Linux/GNU. Bah, ce sont que des raccourscis.
Ca prend 13Mo, mais faut travailler toi meme le path et les variables d'environnement.
Et faire fonctionner GtkTiEmu...

PpHd > ben, en principe ça peut tourner sous d'autres unix, et puis de toute façon il paraît vraisemblable qu'il tourne sur la machine où il est installé...
Pour les variables d'environnement, c'est pas bien compliqué.

Par contre, gtktiemu, c'est vrai que c'est chiant
Si tu veux l'installer, je te conseille de prendre la dernière version dite « stable » (1.53) (en fait elle ne l'est pas mais j'ai essayé la dernière bêta et c'est pire... en plus elle est encore plus chiante à compiler vu qu'elle dépend d'encore plus de bibliothèques externes).
Après il te faut glib/gtk (ça c'est relativement standard, mais je crois que gtk 1.2 et 2.x ne sont pas compatibles, je peux me tromper mais mieux vaut vérifier en tous cas...) et SDL, plus les diverses bibliothèques de l'auteur (il faut au moins libti68k, libticalcs et libticables je crois, et encore d'autres pour la dernière bêta, et je ne suis pas sûr que la dernière version soit toujours celle qui convient... si ça t'intéresse, je peux regarder chez moi avec quelles versions de tout ça j'ai compilé).
Certaines bibliothèques sont sur http://sourceforge.net/projects/gtktiemu et d'autres sur http://sourceforge.net/projects/tilp

Après, c'est buggé mais utilisable.

PiNGoO
: si tu kick tout le monde y'aura plus personne sur ton topic

Je kicke seulement les floodeurs. Encore un message HS et tu en fais partie.

PpHd
: PS: Ca serait cool que tu fasses des raccourcis de m68k-coff-XXX en m68000-ti-linux-gnu-XXX pour tous les programmes. En effet, le terme m68k pour les programmeurs de scripts veut dire > 68020. Ils traitent a part le 68000. Donc des raccourcis seraient biens (mais c'est pas suffisant pour faire fonctionner ces ';';' de scripts configure. J'y arriverais).

Ces outils sont internes, et ils vont bientôt sortir du PATH. (Je vais mettre le PATH comme sous Windows, avec tigcc et tprbuilder dans $TIGCC, tout le reste dans $TIGCC/bin, et $TIGCC dans le PATH à la place de $TIGCC/bin.) Et puis parmi les binutils, seul as restera, tout le reste sera supprimé (plus besoin avec le nouveau linker). Et enfin, je pense qu'il va s'appeler as tout court et plus m68k-coff-as, comme dans la version Windows. Tous ces changements seront faits lors du portage des bêtas 0.95, en correspondance à la version Windows.

liquid :
est ce que ca prend bcp de place tigcc sous unix ? j'ai un compte de 25meg et ca serait cool si je pouvais l'installer

Pour une installation à partir des sources, ça risque de ne pas suffire. (Les sources de GCC et Binutils prennent beaucoup de place.) Pour une installation à partir de binaires, c'est possible, mais le problème est qu'il faut avoir des binaires pour le system *nix sur lequel tu veux l'installer.

PpHd
: Parce que ca fonctionne sous le systeme Linux/GNU. Bah, ce sont que des raccourscis.

Le triplet indiqué est celui du target, pas du host. linux-gnu n'y a rien à faire. Et comme déjà dit, le nom de ces outils ne te regarde pas parce qu'ils sont à usage interne seulement. Il faut appeler tigcc.

suffire

Desole mais 99% des configure appellent directement ces outils donc je souhaite fortement que tigcc dans une optique de bonne compatibilite continue d'avoir ces outils. Deja que c'est penible d'avoir la compatibilite.

PpHd
: Desole mais 99% des configure appellent directement ces outils donc je souhaite fortement que tigcc dans une optique de bonne compatibilite continue d'avoir ces outils. Deja que c'est penible d'avoir la compatibilite.

Nous, on veut une compatibilité continue avec la version Win32. Les scripts configure n'ont jamais été supportés et continueront à ne pas être supportés. AMS n'est pas un *nix, donc les programmes *nix doivent de toute façon être portés à la main. Par conséquent, je ne vois pas l'intérêt de supporter les scripts configure. De plus, il faut obligatoirement passer par le patcher pour compiler correctement un fichier (ce sera moins important avec le nouveau linker, mais des trucs de style USE_FLINE_ROM_CALLS continueront à nécessiter le patcher), donc l'appel direct à ces outils ne fonctionnera très probablement pas.

Mais si tu veux absolument utiliser un script configure, la seule manière qui fonctionne et continuera à fonctionner est:
export CC=tigcc
export AS=tigcc
export LD=tigcc
Le frontend s'occupe de tout.

Et je précise que cette position n'est pas nouvelle. Ma position a toujours été que tout script qui appelle des fichiers au hasard dans $TIGCC/bin, c'est-à-dire autre chose que les interfaces documentées tigcc ou tprbuilder, est bogué et arrêtera de marcher avec les versions futures de TIGCC pour Linux/Unix.

Moi je veux un system TIGcc/GNU qui marche !

LOL, le jour où il y aura une libc POSIX pour AMS, on pourra en reparler. Pas maintenant.
Si tu continues de râler, tu seras considéré comme un troll (et par conséquent kické ).

Si je la fais, tu serais ok ?

À voir.

Mais je pense que le problème des scripts configure peut être règlé autrement que de la manière que tu suggères (cf. mes export; tu peux d'ailleurs mettre des shell-scripts "dummy" qui appellent tigcc si mes exports ne suffisent pas pour règler le problème). Le portage TIGCC des Binutils autres que as est "deprecated" et plus maintenu, donc je n'ai aucune envie de continuer à les installer. Notre tarball des sources de Binutils 2.14 (qui seront utilisées par TIGCC 0.95) ne contient plus que as, d'ailleurs. J'ai complètement zappé les répertoires binutils et ld pour gagner de la place.

./24>Ca serait le pied, ça ! Et si on la couple à une nouvelle table de caractères ASCII DOS standard, ça peut être très sympa pour porter des programmes en mode texte DOS.

De toute acon, tigcc ne compile pas ceci:

void main() {}

alors deja c'est mal parti. Faut que je fasse des replace. Mais je persevere. J'y arriverais,

Pour le problème du main ANSI, je pense m'en occuper un de ces jours (évidemment pour les 2 versions, pas juste pour la version *nix). Mais sache que void main() est incorrect, il faut mettre int main().

Ou mais si je fais ca, il va emettre un warning. "non-void function may return a value" ou un truc du genre.

pquoi void main() est incorect (sous linux la version de gcc que j'utilise refuse de compiler s'il trouve "void main()" en me reclamant le int a la place, mais en revanche il prend "main()" tout cours)

Il faut mettre un return 0; à la fin. Sinon, tu renvoies n'importe quoi comme "exit status"!

PiNGoO
: pquoi void main() est incorect (sous linux la version de gcc que j'utilise refuse de compiler s'il trouve "void main()" en me reclamant le int a la place, mais en revanche il prend "main()" tout cours)

void main() est incorrect parce qu'il faut renvoyer un "exit status" (c'est ce que demande le standard C). Et il prend main() tout cours parce que la valeur de retour par défaut est int, pas void. (D'ailleurs, cet "implicit int" a été supprimé dans le standard C99, donc les compilateurs C99 ne sont pas obligés d'accepter!)