Martial Demolins (./108) :
Pour moi les vraies traductions sont en assembleur, là je comprends rien!

Le CALCULATOR de TIGCC n'existe qu'en C de toute façon. (En assembleur, il faut utiliser __calculator directement en _nostub, et la RAM_CALL directement en kernel.)

stdlib est là pour ça. Surtout que les libs comprises dedans n'évoluent plus depuis un bon moment (les denières maj sont de graphlib et genlib si je ne m'abuse).

Et si elles évoluaient? Ou si on veut utiliser des libs effectivement maintenues? Tout ce que ça me dit, c'est que ces libs sont obsolètes et pas du tout maintenues.

Je suis pas d'accord, si on a de la place en mémoire, alors on s'en fout qu'un seul programme vienne avec toutes ses fonctions de lib statiques.Si on manque de place, on a donc beaucoup de programmes, et il n'est absolument pas dit que l'overhead du kernel dépasse celui de la duplication du code dans tous ces programmes.

Une fois de plus, il y a en général des endroits meilleurs pour économiser de la place, il suffit de regarder tous les programmes compilés en -O2 voire -O3 à la place de -Os. Ou genlib, où même la version "small" pourrait probablement être 2 fois plus petite, et la version "standard" gaspille encore plus de place.

Imagine si on devait recompiler toutes nos applications à chaque bugfix ou update des KDElibs ou je ne sais quel fichier système...

GNU/Linux gère les librairies partagées nativement, avec un système de versions convenable et surtout avec un logiciel (apt, yum, urpmi, smart, emerge, ...) qui permet à l'utilisateur d'installer un programme et d'avoir automatiquement toutes les libs qui vont avec! Sur TI, on n'a rien de tout ça.

ttunpack(_fast-_large), on ne l'appelle pas tous de la même façon

Euh, je l'ai toujours appelé ttunpack_fast, moi, mais je peux l'appeler ttunpack_large si tu insistes.