TIGCC 0.95 Beta 1 pour Windows - Page 3

Oui oui, ça a toujours été le cas chez moi

Voilà ce que j'ai à chaque fois que je veux compiler un projet avec TIGCC 0.95 maintenant : Screenshot.
Je ne vois vraiment pas ce qui lui prend d'aller chercher sur "E:"...

Ca me le faisait avec une acienne version de TIGCC, je pense que tes fichiers son en lecture seul, on essaye de désinstaller TIGCC et de le réinstaller.

Argh, je vais devoir compiler GCC avec un autre préfixe (c:? Ça devrait éviter ce genre de problèmes normalement), ou le patcher pour qu'il n'aille plus fouiller dans le préfixe choisi lors de la compilation. Essaye d'ouvrir GCC.exe avec un éditeur hexadécimal et de remplacer E:/ par C:/, pour voir si ça résout ton problème.

Attend GCC dépend du paramètre précisé lors de la compilation? Et le pack d'installation il sert à quoi dans ce cas?

tigcc.exe lui passe le bon préfixe lors de l'exécution, mais apparemment, il cherche quand-même dans le mauvais.

Un gcc -v montre qu'il cherche certains répertoires d'include. Normalement, il les ignore s'ils n'existent pas, mais sous Win32, Windows peut donner le genre d'erreurs qu'a Vertyos si le lecteur n'existe pas du tout.

Ok, problème résolu (il fallait aussi modifier cc1.exe).

Si ça interesse quelqun, les executables corrigés sont ici

(le lecteur existe sur mon PC, mais comme c'est un graveur et qu'il est vide, ça lance quand même le message)

Tiens, j'ai une autre solution (plus propre): passer -nostdinc à GCC. Je vais dire à Sebastian de le faire automatiquement pour la bêta 2.

Moi j'avais tt le temps ce pb avec la beta 0.94 (là je n'ai pas réessayé), il suffisait que j'insère une disquette dans mon lecteur de disquette, que je fasse au moins une lecture dessus et ensuite, si j'essayais de compiler quelque chose avec TIGCC j'avais comme Vertyos (mais avec A au lieu de E).

Ah, toi c'était carrément avec A:??!!
J'ai parlé du problème à Sebastian, la prochaîne bêta aura un patch dans GCC que je vais mettre pour désactiver la recherche des "includes standard" (comme si -nostdinc était toujours activé).

J'en avais parlé avec nEUrOO je crois, et il m'avait dit que c'était à cause de MinGW...

C'est GCC qui déconne. MSYS y est aussi pour un peu, mais ça peut se corriger sans problèmes dans GCC. En attendant, il y a la version patchée par Vertyos selon mes conseils (E:/->C:/) ou le switch -nostdinc.

g pas encore pu tester, mais d'apres ce que je lis :

Non, car les #defines dans les sources sont obsolètes. Si tu crées un nouveau fichier .c, tu n'auras plus aucun #define mis automatiquement. Les options du projet envoient des switches -D à GCC, ils ne créent pas de #defines. Donc on peut les changer à tout moment.

heu... pas cool pr ceux qui compilent un coup en ligne de commande, un coup sous l'IDE
(enfin, tu me dira suffit de passer mles -D sous la ligne de commande... mais ça rallonge encore les commandes )


le coup du lecteur E, ca me l'a fait des fois...
ou avec un autre lecteur, je sais plus;
sachant que le lecteur pr lequel ca le faisait etait un graveur, aussi
ca me le faisait qd je lancait tigcc avec un cd dans le lecteur, et que, ensuite, je n'avais plus de cd dans le lecteur => il trouvait pas le cd///

squale92
:

Non, car les #defines dans les sources sont obsolètes. Si tu crées un nouveau fichier .c, tu n'auras plus aucun #define mis automatiquement. Les options du projet envoient des switches -D à GCC, ils ne créent pas de #defines. Donc on peut les changer à tout moment.

heu... pas cool pr ceux qui compilent un coup en ligne de commande, un coup sous l'IDE

tprbuilder --help

(enfin, tu me dira suffit de passer mles -D sous la ligne de commande... mais ça rallonge encore les commandes )

Et alors? Si tu ne veux pas taper des lignes de commande longues à chaque fois, crée un batchfile ou un shell script, ou alors un makefile, ou alors utilise tprbuilder.

Et cette approche est nettement plus propre. En particulier, cette approche évite un problème fréquent: la non-correspondance des options choisies entre plusieurs fichiers .c. Tous les fichiers .c doivent être compilés avec les mêmes options pour que ça marche. (Exception: #define _GENERIC_ARCHIVE permet de créer des fichiers utilisables quelles que soient les options, ce qui est important pour les librairies statiques.) Et puis, pour la ligne de commande, l'utilisation de -D permet aussi de passer toutes les options au même endroit, qu'elles soient des options du compilateur, du linker ou de TIGCCLIB.

le coup du lecteur E, ca me l'a fait des fois...
ou avec un autre lecteur, je sais plus;
sachant que le lecteur pr lequel ca le faisait etait un graveur, aussi ca me le faisait qd je lancait tigcc avec un cd dans le lecteur, et que, ensuite, je n'avais plus de cd dans le lecteur => il trouvait pas le cd///

Je vais patcher GCC proprement pour la prochaine bêta (du moins j'espère que j'aurai le temps avant la prochaine bêta). En attendant, tu peux utiliser le quick hack que j'ai conseillé plus haut dans le topic, ou récupérer les binaires patchés avec ma méthode rapide par Vertyos, ou utiliser le switch -nostdinc.

Je viens d'avoir la mauvaise idée de vouloir reprendre un projet sur Ti, et donc d'utiliser TIGCC 0.95 :

• J'avais une librairie statique qui marchait sans aucun problème, compilée avec TIGCC 0.94 SP4. Je l'ai recompilée avec TIGCC 0.95 b1, aucun warning à la compilation, et maintenant lors de l'inclusion à un projet, voilà ce que j'ai :
http://perso.club-internet.fr/vertyos/Images/Screenshots/TIGCCBug01.png

• [Edit] Supprimé, j'ai trouvé comment résoudre le problème. Reste un bug

Du coup je suis bloqué

Ce n'est pas une erreur du linker, ça, donc ça doit être l'assembleur qui donne une erreur, donc c'est dans ton projet qu'il y a un problème, pas dans la librairie statique. Comme d'habitude, sans le projet qui donne l'erreur, je ne peux pas dire s'il s'agit d'un bogue de TIGCC, ni où il est si c'est le cas.

Ni le projet ni la librairie n'ont été modifiés j'ai simplement essayé de recompiler avec la nouvelle version de TIGCC. Même si ce n'est pas un bug, c'est au moins une incompatibilité (quelque chose me dit que pour une fois tu seras d'accord avec moi : ce n'est pas la même chose ).

[Edit] Je doute que ce soit le projet qui soit en cause : en mettant une vieille version de la librairie à la place de la nouvelle, ça compile.

Vertyos> J'ai constaté le même bug quand il y avait un problème dans ma librairie statique.
Kevin> Si on utilise une ancienne librairie statique, TIGCC 0.95 compilera correctement? Et si on utilise une librairie statique faite sous TIGCC 0.95, les anciennes version compilerons correctement?

Je ne comprends pas cette histoire! Cette erreur n'est pas une erreur de ld-tigcc, et ld-tigcc est le seul programme à traîter les librairies statiques une fois compilées. Le problème n'est pas dans la librairie statique.

Et je réitère: envoie-moi les sources qui ne compilent pas, je ne peux rien faire sans. Comment se fait-il que vous n'avez toujours pas compris ça?

Ah oui, un autre truc: la première fois que vous compilez vos projets avec une nouvelle version de TIGCC, faites un Project/Build (tout recompiler), pas un Project/Make. Peut-être que c'est ça le problème.

Pour les librairies statiques, les librairies statiques créées avec TIGCC 0.94 devraient marcher avec TIGCC 0.95, mais pas dans l'autre sens.

OK donc mon le message que j'avais était une compilation de ma librairie faite sous TIGCC 0.95 compilé sous TIGCC 0.94.

Bon pour éviter de perdre du temps je vais t'envoyer un programme d'une dizaine de lignes et la librairie puisque c'est elle qui bug, pas le projet.

OK, merci, je vais voir ce qui cloche.

1. La version de TIGCC avec laquelle tu as linké ton projet n'était certainement pas TIGCC 0.95 bêta 1, parce que avec TIGCC 0.95 bêta 1, je n'ai pas tes "DISP16" illisibles, mais "Relative reloc at ... to `FontData' in different section". Tu ne peux pas utiliser une librairie statique compilée avec TIGCC 0.95 sous TIGCC 0.94 (mais dans l'autre sens, tu peux, il y a compatibilité antérieure, mais pas postérieure).
2. Ce n'est pas un bogue, c'est une erreur d'utilisateur qui ressemble à ton utilisation invalide de -l dans le "bogue" que tu m'avais reporté tout au début de la phase de bêta. C'est un (PC) utilisé de manière invalide en assembleur. Vire le (PC) ou passe -mno-bss à GCC.
Bref, double erreur d'utilisateur, "bug report" invalide, il n'y a aucun bogue.

PS: J'ai eu le même problème avec Task Switcher, et j'ai mis un -mno-bss tout simplement.

Kevin Kofler :
Tu ne peux pas utiliser une librairie statique compilée avec TIGCC 0.95 sous TIGCC 0.94 (mais dans l'autre sens, tu peux, il y a compatibilité antérieure, mais pas postérieure).

J'utilise une librairie recompilée avec TIGCC 0.95 b1 sur un projet, toujours avec TIGCC 0.95 b1. J'ai fait l'essai avec aussitot après avoir vu que ça ne marchait plus sous TIGCC 0.94 SP4.

2. Ce n'est pas un bogue, c'est une erreur d'utilisateur qui ressemble à ton utilisation invalide de -l dans le "bogue" que tu m'avais reporté tout au début de la phase de bêta. C'est un (PC) utilisé de manière invalide en assembleur. Vire le (PC) ou passe -mno-bss à GCC.

Dans ce cas c'est une incompatibilité entre TIGCC 0.94 SP4 et TIGCC 0.95 b1. Je suis désolé, mais en recompilant les deux projets avec la dernière beta ça ne marche pas. D'ailleurs ça fait la 3eme fois que cette %$^*ù$ option de "bss" est en cause, à se demander si c'était une bonne idée de la laisser activée par défaut pour les .tpr qui venaient de versions anterieures de TIGCC.

(utiliser -mno-bss a effectivement résolu le problème, mais ça reste une incompatibilité)

Utiliser une référence PC-relative à une variable dont on ne connaît pas l'emplacement précis (ni même la section choisie par le compilateur) a toujours été une erreur d'utilisateur. Tu as eu de la chance que ça avait marché avant, ça n'a jamais été supporté.

La beta 2 est sortie ou pas au fait ?

Pas encore.

J'ai un peu l'impression que tu définis les erreurs comme ça t'arrange. Cela dit ma remarque sur l'activation par défaut des "bss" reste en attente : ça rend incompatibles un bon nombre de programmes lors de la conversion 0.94 -> 0.95.
A part ça, moins important, mais tu pourras dire à Sebastian que la nouvelle version de l'IDE supporte mal les skins sous XP (la barre de menu prend des teintes étranges).