> Heu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?
De fait, les binaires produits devraient être identiques dans les deux cas (compilation native ou croisée).
L'intérêt de la compilation native d'un OS est de permettre de tester, tout en compilant, un bon nombre de composants binaires délicats produits lors de la compilation précédente : la libc, le noyau (vm, système de fichier, ...), les binutils, l'éditeur de lien, le compilateur, make, le shell, ld.so, etc., C'est un échantillon représentatif de logiciels critiques, et cela permet de découvrir bon nombre de problèmes (par ex. les cas où la précédente compilation a produit de mauvais binaires) suffisamment tôt pour corriger et ne pas distribuer ces binaires. Au final, ça permet comme le dit le commentaire parent de « fournir des binaires de qualité », mais pas spécialement de « produire des binaires de qualité » bien sûr.
C'est aussi la démarche de Debian (qui, de ce fait, et pour ne pas masquer un problème qui pourrait se produire sur l'architecture cible, proscrit - ou proscrivait ? est-ce que ça a changé ? - même la production des deb finaux dans des machines virtuelles). Debian est dans une position similaire à OpenBSD dans la mesure ou ce projet rassemble une belle proportion d'amateurs qui travaillent pour le plaisir - ou du moins, qui ne sont pas asservis aux seuls besoins de rentabilité et d'attentes sur un marché - ce qui explique dans les deux cas qu'ils puissent investir des efforts conséquents pour supporter des architectures « non rentables ».
Confronté aux mêmes problèmes (lenteur de gcc sur les vielles machines, compilateur maintenu par des grosses boite intéressées seulement par les principales archis en vente aujourd'hui (x86, x86_64, ppc, itanium, arm, s390) et qui évolue rapidement sans trop se préoccuper des architectures exotiques, etc.), le projet Debian a lui aussi du prendre des décisions douloureuses. En l'occurrence, il a été décidé d'abandonner le support officiel pour les architectures qui ne parviennent pas à suivre la cadence de compilation (entre autres critères).
Une autre limitation de la cross-compilation est que tout logiciel n'est pas « naturellement » cross-compilable. Certains logiciels exécutent au cours de la compilation des binaires produits dans une phase précédente. C'est par exemple cas de python : un interpréteur minimal est initialement produit, qui sert à piloter le reste de la compilation et doit, de ce fait, être exécuté sur la plateforme qui compile. D'autres logiciels utilisent des systèmes de compilation (autres que autotools ou CMake) n'offrant pas de facilités pour la cross-compilation. Les solutions à ces problèmes relèvent généralement du bricolage fragile : patcher lourdement le logiciel à compiler, ou intercepter l'exécution des binaires étrangers pour les rediriger dans un émulateur en espace utilisateur, ...
[^] # Re: Besoins d'OpenBSD
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 9.
De fait, les binaires produits devraient être identiques dans les deux cas (compilation native ou croisée).
L'intérêt de la compilation native d'un OS est de permettre de tester, tout en compilant, un bon nombre de composants binaires délicats produits lors de la compilation précédente : la libc, le noyau (vm, système de fichier, ...), les binutils, l'éditeur de lien, le compilateur, make, le shell, ld.so, etc., C'est un échantillon représentatif de logiciels critiques, et cela permet de découvrir bon nombre de problèmes (par ex. les cas où la précédente compilation a produit de mauvais binaires) suffisamment tôt pour corriger et ne pas distribuer ces binaires. Au final, ça permet comme le dit le commentaire parent de « fournir des binaires de qualité », mais pas spécialement de « produire des binaires de qualité » bien sûr.
C'est aussi la démarche de Debian (qui, de ce fait, et pour ne pas masquer un problème qui pourrait se produire sur l'architecture cible, proscrit - ou proscrivait ? est-ce que ça a changé ? - même la production des deb finaux dans des machines virtuelles). Debian est dans une position similaire à OpenBSD dans la mesure ou ce projet rassemble une belle proportion d'amateurs qui travaillent pour le plaisir - ou du moins, qui ne sont pas asservis aux seuls besoins de rentabilité et d'attentes sur un marché - ce qui explique dans les deux cas qu'ils puissent investir des efforts conséquents pour supporter des architectures « non rentables ».
Confronté aux mêmes problèmes (lenteur de gcc sur les vielles machines, compilateur maintenu par des grosses boite intéressées seulement par les principales archis en vente aujourd'hui (x86, x86_64, ppc, itanium, arm, s390) et qui évolue rapidement sans trop se préoccuper des architectures exotiques, etc.), le projet Debian a lui aussi du prendre des décisions douloureuses. En l'occurrence, il a été décidé d'abandonner le support officiel pour les architectures qui ne parviennent pas à suivre la cadence de compilation (entre autres critères).
Une autre limitation de la cross-compilation est que tout logiciel n'est pas « naturellement » cross-compilable. Certains logiciels exécutent au cours de la compilation des binaires produits dans une phase précédente. C'est par exemple cas de python : un interpréteur minimal est initialement produit, qui sert à piloter le reste de la compilation et doit, de ce fait, être exécuté sur la plateforme qui compile. D'autres logiciels utilisent des systèmes de compilation (autres que autotools ou CMake) n'offrant pas de facilités pour la cross-compilation. Les solutions à ces problèmes relèvent généralement du bricolage fragile : patcher lourdement le logiciel à compiler, ou intercepter l'exécution des binaires étrangers pour les rediriger dans un émulateur en espace utilisateur, ...