mdr1: je suis au courant que freetype ne dépend pas de XLib / XCB, par exemple - mais comme l'a indiqué Adriweb, même la librairie C
est un problème sur Nspire.
Je crois que tu n'as pas encore assez pris conscience du point auquel, par la faute de la politique contre-productive de TI, la plate-forme Nspire n'est pas sympa à programmer en C/ASM et n'attire pas les programmeurs
C'est si compliqué que ça de porter g++ ?
Porter GCC vers un nouvel hôte, pas trop. Porter GCC vers une nouvelle target, pas très simple. Mais ici, il n'y aurait pas à porter vers une nouvelle target.
Sachant qu'on a réussi à porter gcc, g++ ne devrait pas être tellement plus dur. (et puis, je suis sûr qu'il est déjà porté pour ARM).
gcc n'a été porté pour Nspire que grâce à Linux ouvert et documenté, et g++ a les mêmes dépendances. Pour Nucleus+Phoenix fermé et non documenté, nous essayons de signifier que c'est plus difficile - surtout que le support bFLT n'est pas encore intégré à Ndless de façon utilisable, il y a un problème technique. Voir le topic que mdr1 a créé sur Omnimaga.
De toute façon, avec aussi peu de RAM, gcc, et encore plus g++, serait incapable de compiler des programmes un tant soit peu complexes en un temps acceptable (et l'utilisation de swap externe sur MSD USB n'améliorerait pas les choses, tant le débit est limité). Les plus puissantes boards ARM de 2011-2013, au moins 50 fois plus puissantes que la Nspire (Cortex A9 quad @ 1.7 GHz, 2 GB RAM - en attendant, avant la fin du premier semestre, des Cortex A15 quad @ probablement au moins 2 GHz et 4+ GB RAM), sont capables de compiler presque tout programme C/C++ avec gcc/g++/clang/clang++; mais la Nspire, fût-elle la plus puissante calculatrice du marché, est, en absolu, très peu puissante (et très chère).
D'ailleurs, pourquoi personne n'a créé de repository de reverse engineering avec le désassemblage ?
Hmm... un tel repository existe, et comme Ndless, il est publiquement accessible, je viens de vérifier
Comme ça, n'importe qui pourrait aider à trouver les syscalls et leur correspondant dans les librairies standards.
"n'importe qui", en pratique, est "presque personne"...
Pas besoin de reverse engineer en C, il suffit de comprendre à quelle fonction standard elle correspond ou comprendre son utilité si elle ne fait pas partie de la librairie standard.
Il
suffit de, tout à fait. Cependant, le fait est que le reverse-engineering complet n'est fait ni pour TI-Z80, ni pour TI-68k; et l'OS des Nspire est beaucoup plus récent, beaucoup plus gros et plus complexe, donc beaucoup plus difficile et coûteux en temps à
reverse engineer J'imagine que l'on pourrait récupérer une liste des syscalls et leur offset + désassemblage avec IDA et ensuite poster ça sur un repo genre github ou code.google.com
Liste des routines, c'est ce qui existe déjà dans un repo SVN public
Vous en pensez quoi ? Cela ne devrait pas trop prendre de temps et permettrait de mettre à jour les syscalls simplement.
J'en pense que c'est une bonne idée, et qu'elle est du reste implémentée depuis assez longtemps
Mais en pratique, sache que la possibilité de mettre à jour les syscalls simplement est très théorique. Ce n'est pas aussi simple qu'on peut l'imaginer, pas parce que l'info n'est pas accessible publiquement, mais parce que ce n'est réellement pas si simple que ça, et parce que presque personne n'a à la fois l'intérêt et le temps.
Pour avoir une meilleure idée des raisons qui font que ce n'est pas trivial, tu peux essayer par toi-même d'utiliser l'OS 3.1.0.392 comme base pour les syscalls de l'OS 3.2.0.1212, 3.2.0.1219 ou 3.2.3.1233
by 
