C'est faisable (et d'ailleur, c'est souvent ce que fait le framework OpenEmbedded dans ce genre de cas). Mais :
1- ça exige généralement d'énormes patches sur les Makefiles (pas faciles à maintenir).
2- ça peut produire un résultat non fonctionnel: ces outils qui s'éxecutent en cours de route servent notamment à invoquer les bonnes options (CFLAGS/CXXFLAGS adéquats, paths, -L../-l../-I.. etc.) pour le reste de la compil. Et il n'est pas rare que ces options diffèrent entre l'hôte et la cible :(
3- ça peut rendre la compilation difficile à automatiser.
4- il est parfois difficile d'avoir sur l'hote source une config logicielle équivalente à celle de la cible. Surtout si la cible est un appareil embarqué, avec, typiquement, utilisation d'un framebuffer spécial, ou de nanox (vs outils linkés sur X windows sur l'hote), ou toute autre différence matérielle ; ce qui agrave les problèmes listés en "2-" (c'est du vécu ;).
[^] # Re: Pas grave ...
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 3.
1- ça exige généralement d'énormes patches sur les Makefiles (pas faciles à maintenir).
2- ça peut produire un résultat non fonctionnel: ces outils qui s'éxecutent en cours de route servent notamment à invoquer les bonnes options (CFLAGS/CXXFLAGS adéquats, paths, -L../-l../-I.. etc.) pour le reste de la compil. Et il n'est pas rare que ces options diffèrent entre l'hôte et la cible :(
3- ça peut rendre la compilation difficile à automatiser.
4- il est parfois difficile d'avoir sur l'hote source une config logicielle équivalente à celle de la cible. Surtout si la cible est un appareil embarqué, avec, typiquement, utilisation d'un framebuffer spécial, ou de nanox (vs outils linkés sur X windows sur l'hote), ou toute autre différence matérielle ; ce qui agrave les problèmes listés en "2-" (c'est du vécu ;).