Forum TI-Planet.org

Salut tout le monde !

Je rencontre une erreur à la compilation de gcc4ti/trunk/ktigcc (récupéré avec la commande git depuis https://github.com/debrouxl/gcc4ti)

Voici l'erreur à l'exécution de la commande `make` :

Code: Tout sélectionner

<snip />
g++ -m64 -o ktigcc .obj/ktigcc.o .obj/preferences.o .obj/tpr.o .obj/tiemu_stub.o .obj/callbacks.o .obj/parsing.o .obj/completion.o .obj/srcfilewin.o .obj/projectoptions.o .obj/programoptions.o .obj/preferencesdlg.o .obj/mainform.o .obj/errorlist.o .obj/programoutput.o .obj/functions.o .obj/newsdlg.o .obj/toolsdlg.o .obj/toolprops.o .obj/selectstyle.o .obj/selectcolors.o .obj/customstyle.o .obj/wordlist.o .obj/moc_tiemu_stub.o .obj/moc_completion.o .obj/moc_srcfilewin.o .obj/moc_projectoptions.o .obj/moc_programoptions.o .obj/moc_preferencesdlg.o .obj/moc_mainform.o .obj/moc_errorlist.o .obj/moc_programoutput.o .obj/moc_functions.o .obj/moc_newsdlg.o .obj/moc_toolsdlg.o .obj/moc_toolprops.o .obj/moc_selectstyle.o .obj/moc_selectcolors.o .obj/moc_customstyle.o .obj/moc_wordlist.o .obj/qrc_icons.o    -L/usr/lib/x86_64-linux-gnu -lktexteditor -lkutils -lkdeui -lkdecore -lkio -lkparts -lkde3support -lticonv -lticables2 -ltifiles2 -L/usr/local/lib -lticalcs2 -lglib-2.0 -lQtAssistantClient -lQtDBus -lQt3Support -lQtXml -lQtGui -lQtNetwork -lQtCore -lpthread
/usr/bin/ld: .obj/newsdlg.o: undefined reference to symbol '_ZN13KCMultiDialogC1EP7QWidget'
/usr/bin/ld: //usr/lib/libkcmutils.so.4: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [Makefile:195: ktigcc] Error 1


Mon OS est Devuan, basé sur Debian. J'ai bien fait attention d'installer des libs de qt4, même si qt5 a depuis pris une part importante dans le repository.

Merci de m'aiguiller

Le seul conseil que je puisse te donner, c'est d'arrêter tout de suite d'essayer de compiler, et a fortiori d'utiliser, cette vilaine réécriture in-maintenable (le code est horrible, un des pires que je connaisse), et qui cherche à rester parfaitement compatible sans corriger les défauts, de l'IDE Delphi pour Windows
* au mieux, KTIGCC 4 marchouillait pour une des premières versions de KDE 4.x, à l'époque où KDE 4 était encore inutilisable (avant 4.4), mais le code n'a jamais été adapté pour fonctionner avec des versions plus modernes, dont les classes ont changé;
* les TPRs utilisés par l'IDE Delphi et KTIGCC sont fonctionnellement limités et peuvent être désagréables à utiliser dans des use cases relativement simples. J'ai utilisé des TPRs dans plusieurs programmes de TICT avant de comprendre à quel point les TPRs étaient limités (ce dont se plaignaient plusieurs développeurs de la communauté, que je n'ai pas écoutés à l'époque). Et encore, pour que leur utilisation soit moins désagréable, j'ai contribué une amélioration à tprbuilder... tprbuilder, c'est l'outil en ligne de commande pour construire des TPRs, et ça ne fonctionne pas de la même façon avec les IDEs et avec tprbuilder.

Plutôt que les IDEs, utilise plutôt:
* tprbuilder en ligne de commande, ou mieux mais plus difficile à utiliser, un script sh qui invoque `tigcc` de façon répétée, en faisant attention que les options de compilation soient cohérentes. J'ai fait (enfin, fait évoluer au cours du temps) un jeu correct dans TI-Chess, par exemple.
* le transfert manuel de programmes vers TIEmu. D'ailleurs, il est très important d'utiliser la version non GDB de TIEmu: la version GDB est plus buggée que la version non GDB, et beaucoup plus difficile à compiler. Il y a toutes les chances que le build de la version GDB échoue lamentablement sur toutes les distros de moins de quelques années. Malgré la complexité additionnelle, Romain Liévin a eu, comme souvent, raison d'exiger que TIEmu reste utilisable sans GDB: dans la version GDB, le mélange d'event loops et de forks de versions lourdement obsolètes de logiciels GNU, collés ensemble par un système de build fragile, est complètement in-maintenable...

TL;DR: KTIGCC caca, TPR caca, TIEmu GDB caca, rien n'est maintenu depuis longtemps.
Tu arrives... 13 ans après la grosse baisse d'activité de la communauté

Meh tant pis
De toutes façons, je ne sais ni coder direct en ASM, ni en C++ ... tout juste un peu de PERL, shell et TI-BASIC
C'était juste par curiosité. Merci de ta réponse

Alors tu seras tout à fait capable de te passer d'un IDE, que mon post honnête ne te décourage pas d'essayer de faire des programmes ASM TI-68k en C (C++ n'est pas géré par GCC4TI)

Merci pour ce message encourageant

J'ai une dernière question : En 2020 , Quel est le meilleur outil pour compiler un programme ? Est-ce que le GCC standard ('m68k') suffit ? Ou bien, faut-il toujours utiliser tigcc ?

Cette doc est-elle toujours d'actualité ? http://debrouxl.github.io/gcc4ti/

Un grand merci par avance !

Toute la toolchain de GCC4TI est fortement customisée, des headers qui utilisent des fonctionnalités qui n'existent que dans cette toolchain au linker spécifique (ld-tigcc) en passant par le compilateur (m68k-coff-tigcc-gcc) et l'assembleur (m68k-coff-tigcc-as). Pour cibler les TI-68k, le moins mal est donc d'utiliser GCC4TI, en principe exclusivement à travers le front-end CLI `tigcc`. Il faut compiler sous Debian 8 (qui ne sera bientôt plus maintenue), parce qu'il y a des problèmes avec les versions plus récentes de GCC...

Pour cibler les TI-68k, utiliser un GCC m68k standard, peut-être un peu patché par Debian, est plutôt une mauvaise idée, voir par exemple https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88589 . Et puis ça fait beaucoup plus longtemps que ça que la performance sur m68k a diminué, voir par exemple https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454 .

Et oui, la doc en ligne est toujours d'actualité, mais de toute façon, le script de build de GCC4TI fait des choses avec les fichiers de doc