Donc je repose la question: à quoi bon permettre de compiler le reste de TIGCC avec autre chose que GCC si de toute façon le composant le plus essentiel ne le supporte pas?

Comme tu le sais, GCC n'est pas le seul outil de GCC4TI qui produit des fichiers objet; et le linker, dont tu es un des deux principaux programmeurs, est la seule façon supportée de produire des exécutables au format de fichiers TI-68k/AMS (.xxz) à partir de fichiers objet.
Garder du code bien connu comme non portable et créateur d'incompatibilités gratuites n'est pas justifiable (quand on est au courant d'un cas pratique où ça emmerde), compte tenu de la facilité de correction et de la réduction d'utilisabilité que représente l'absence de linker. Donc, il y avait deux sources de problèmes de compilation dans GCC4TI avec Clang, et il n'y en a maintenant plus qu'une. C'est tout, et ça n'empêche pas qu'il faut actuellement construire le GCC de GCC4TI avec GCC, puisque GCC n'est compilable qu'avec GCC...

Je ne te demande pas d'être d'accord avec mes opinions et mes actions; en revanche, arrête tes "totalement inutile", "ça n'a pas de sens", et autres formules à l'emporte-pièce de ce genre pour critiquer des choses dans GCC4TI quand il devrait t'être évident, si tu réfléchissais un peu (et avec une vision moins étriquée que Linux-GCC-binutils), qu'il y a une justification, du sens et de l'utilité !

Un script en #!/bin/bash est parfaitement portable, il a le même comportement partout. Avec un script en #!/bin/sh, tu exposes tes utilisateurs à tous les shells Bourne-like possibles et imaginables, avec leurs bogues et limitations.

N'inverse pas les choses. En pratique, les scripts qui ont de vrais problèmes de portabilité dès qu'on essaie de compiler sur autre chose que Linux - ce qui est le cas dans ce topic - sont les scripts de TIGCC.
Les scripts de GCC4TI fonctionnent sous diverses familles de Linux (même des familles où /bin/sh n'est pas bash), FreeBSD (où /bin/sh n'est pas bash), MacOS X OpenSolaris, et pour la cross-compilation pour Windows sur Linux. Pas de bugs avec "tous les shells Bourne-like possibles et imaginables" en vue sur ces plate-formes.
De toute façon, nous n'utilisons aucune construction avancée, seulement des trucs suffisamment basiques pour que si le shell se foire dessus, d'autres choses ne fonctionnent pas, bien avant les scripts de compilation de GCC4TI ^^