> Les __need_in_use_bit ne sont plus que dans les headers, il y en a aussi dans tigcc.a maintenant (parce que tigcc.a a été recompilée avec les headers à jour).
Oui, je sais (même si je l'avais oublié).
Je ne pense pas qu'il y ait trop de __need_in_use_bit spurious induits dans tigcc.a. Ce ne sera pas forcément nécessaire de reconstruire tigcc.a (ce qui est l'affaire d'une dizaine de secondes au plus... ExtGraph est un projet nettement plus gros, et prend une quinzaine de secondes sur une machine moins puissante...).

"tictex" a NEED_IN_USE_BIT, et c'est nécessaire car c'est un programme qui en lance d'autres.
"tictexpl" ne l'a pas, sauf éventuel import (probablement) spurious.
Mais quand les headers non patchés de TIGCCLIB infligent le workaround du bug d'AMS à mon implémentation d'un delta² d'Aitken, petit programme d'un peu plus de 400 octets, augmentant sa taille d'un quart environ, sans que personne soit capable de donner une raison logique à ce que les fonctions du CAS nécessitent __need_in_use_bit (et sachant que les callgraphs ont été réalisés avec un outil dont on a perdu les sources, et dont j'ai trouvé et reporté au moins un bug faussant le callgraph, sur OSVRegister/FreeTimer...), je ne suis pas satisfait.

[EDIT: cross.
> > Et les plug-ins permettant de faire évoluer les fonctionnalits ?
> Une architecture à plug-ins sur TI, ça ne fait que des fichiers de plus à envoyer, il vaut mieux tout linker dans l'exécutable, et comme ça on évite aussi les problèmes de protection.
+1. On est en embarqué assez dur, ici, et c'est sympa de profiter du linking statique et des références d(pc) si la source et la cible ne sont pas trop loin)...
]