Lionel Debroux (./14) :
Je sais parfaitement que TIGCC n'a jamais supporté autre chose que GCC, je l'ai même posté pas plus tard que tout à l'heure en ./11. Mais tu sais, la première décennie du 21ème siècle est finie depuis plus de deux ans et demi: il y a un autre compilo C/C++ d'excellente facture, le plus compatible avec GCC, qui devient le compilo standard de la plate-forme dont il est question dans ce topic, pour des raisons techniques et non techniques.
Il est donc naturel de voir ce que cet autre compilo fait avec la base de code dont il est question dans ce topic (j'ai vu), et il n'est pas interdit de corriger des incompatibilités triviales et gratuites avec les standards dans une base de code qui se veut portable, avant qu'elles emmerdent les utilisateurs.

Est-ce que GCC upstream supporte de compiler un cross-GCC avec clang maintenant? Ça m'étonnerait, ils ont toujours été clairs sur ça: soit un fait un bootstrap complet (possible seulement en natif), soit on compile avec GCC. (Et en tout cas c'était le cas quand ils ont sorti le GCC sur lequel GCC4TI s'appuie toujours.) 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?

Ce n'est pas parce qu'une modification n'est pas utile à toi, qui ne te soucies que de Linux et de GCC/binutils, qu'elle est "totalement inutile". En l'occurrence, comme l'autre modification de GCC4TI que tu critiques, elle a une utilité.

Une fois de plus: changer #!/bin/bash en #!/bin/sh ne fait qu'augmenter les problèmes de portabilité (et bash est parfaitement disponible sous OS X, ils en ont même fait le shell par défaut, à moins que ça n'ait changé à nouveau). 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.