Pourquoi FreeBSD déprécie GCC en faveur de Clang / LLVM?
Je surfais donc sur le net et suis tombé sur cet article . Il indique essentiellement que FreeBSD , à partir de la version 10 et supérieure, rendra obsolète GCC en faveur de Clang/LLVM .
D'après ce que j'ai vu sur le net jusqu'à présent, Clang/LLVM est un projet assez ambitieux, mais en termes de fiabilité, il ne peut pas correspondre GCC .
Y a-t-il des raisons techniques pour lesquelles FreeBSD choisit LLVM comme infrastructure de compilation, ou est-ce que tout se résume aux licences GNU/GPL et BSD éternelles?
Cette question contient (en quelque sorte) des informations pertinentes sur l'utilisation de GCC in FreeBSD
Résumé: La raison principale du passage de GCC to Clang est l'incompatibilité de la licence GPL v de GCC avec la objectifs du projet FreeBSD . Il y a aussi des problèmes politiques liés à l'investissement des entreprises, ainsi que les exigences de la base d'utilisateurs. Enfin, il existe des avantages techniques attendus liés à la conformité aux normes et à la facilité de débogage. Les améliorations des performances réelles dans la compilation et l'exécution sont spécifiques au code et discutables; des cas peuvent être créés pour les deux compilateurs.
FreeBSD et la GPL: FreeBSD a une relation difficile avec la GPL. Les partisans de la licence BSD pensent qu'un logiciel vraiment gratuit a pas de restrictions d'utilisation . Les partisans de la GPL estiment que des restrictions sont nécessaires afin de protéger la liberté du logiciel, et en particulier que la possibilité de créer des logiciels non libres à partir de logiciels libres est un forme injuste de pouvoir plutôt que une liberté. Le projet FreeBSD, dans la mesure du possible, essaie de éviter l'utilisation de la GPL :
En raison des complexités supplémentaires qui peuvent évoluer dans l'utilisation commerciale des logiciels GPL, nous nous efforçons toutefois de remplacer ces logiciels par des soumissions sous la licence FreeBSD plus détendue chaque fois que possible.
FreeBSD et la GPL v3: Le GPL v interdit explicitement le soi-disant Tivoisation de code , une faille dans le GPL v2 qui permettait aux restrictions matérielles d'interdire les modifications logicielles autrement légales par les utilisateurs. Fermer cette échappatoire était une étape inacceptable pour beaucoup dans la communauté FreeBSD:
Les fournisseurs d'appareils en particulier ont le plus à perdre si le grand nombre de logiciels actuellement sous licence GPLv2 migre aujourd'hui vers la nouvelle licence. Ils n'auront plus la liberté d'utiliser le logiciel GPLv3 et de restreindre la modification des logiciels installés sur leur matériel ... Bref, il existe une large base de consommateurs OpenSource qui sont soudain très intéressés à comprendre des alternatives aux logiciels sous licence GPL.
En raison du passage de GCC à la GPL v3, FreeBSD a été contraint de continuer à utiliser GCC 4.2.1 (GPL v2), qui était sortie en 2007 , et est désormais considérablement dépassé. Le fait que FreeBSD ne soit pas passé à l'utilisation de versions plus modernes de GCC, même avec les maux de tête de maintenance supplémentaires liés à l'exécution d'un ancien compilateur et de correctifs de rétroportage, donne une idée de la force de l'exigence d'éviter la GPL v3. Le compilateur C est un composant majeur de la base FreeBSD, et " l'un des objectifs (provisoires) de FreeBSD 10 est un système de base sans GPL ".
Investissement des entreprises: Comme de nombreux grands projets open source, FreeBSD reçoit financement et travaux de développement des entreprises . Bien que la mesure dans laquelle FreeBSD est financé ou donné le développement par Apple n'est pas facilement détectable, il y a un chevauchement considérable parce qu'Apple Darwin OS utilise un important BSD d'origine - code du noya . De plus, Clang lui-même était à l'origine un projet interne Apple projet, avant d'être open-source en 2007 . Puisque les ressources de l'entreprise sont un catalyseur clé du projet FreeBSD, répondre aux besoins des sponsors est probablement n moteur significatif dans le monde réel .
Base d'utilisateurs: FreeBSD est une option open source attrayante pour de nombreuses entreprises, car la licence est simple, sans restriction et peu susceptible d'entraîner des poursuites. Avec l'arrivée de la GPL v3 et des nouvelles dispositions anti-tivoisation , il a été suggéré qu'il y avait une tendance accélérée, dirigée par les fournisseurs, vers des licences plus permissives . Étant donné que l'avantage perçu de FreeBSD pour les entités commerciales réside dans sa licence permissive, il y a une pression croissante de la part des utilisateurs d'entreprise pour s'éloigner de GCC, et de la GPL en général.
Problèmes avec GCC: En dehors de la licence, l'utilisation de GCC a certains problèmes perçus . GCC n'est pas entièrement conforme aux normes et a de nombreuses extensions ne figurent pas dans la norme ISO C . Avec plus de 3 millions de lignes de code, c'est aussi " l'un des projets logiciels les plus complexes et gratuits/open source ". Cette complexité rend la modification du code au niveau de la distribution une tâche difficile.
Avantages techniques: Clang a quelques avantages techniques par rapport à GCC . Les plus notables sont messages d'erreur beaucoup plus informatifs et un API explicitement conçue pour les IDE, le refactoring et les outils d'analyse de code source. Bien que le site Web de Clang présente des graphiques indiquant une compilation et une utilisation de la mémoire beaucoup plus efficaces, les résultats réels sont assez variables , et globalement conformes aux performances de GCC. En général, les binaires produits par Clang s'exécutent plus lentement que les binaires GCC équivalents:
Bien que l'utilisation de LLVM soit plus rapide à construire du code que GCC ... dans la plupart des cas, les binaires construits par GCC 4.5 avaient mieux performé que LLVM-GCC ou Clang ... dans le reste des tests, les performances étaient soit proches de celles de GCC ou bien derrière. Dans certains tests, les performances des binaires générés par Clang étaient tout simplement horribles.
Conclusion: Il est très peu probable que l'efficacité de la compilation soit une motivation importante pour prendre le risque substantiel de déplacer un grand projet comme FreeBSD vers une toute nouvelle chaîne d'outils de compilation, en particulier lorsque les performances binaires font défaut. Cependant, la situation n'était pas vraiment tenable. Étant donné le choix entre 1) exécuter un GCC obsolète, 2) passer à un GCC moderne et être obligé d'utiliser une licence incompatible avec les objectifs du projet ou 3) passer à un compilateur stable sous licence BSD, la décision était probablement inévitable. Gardez à l'esprit que cela ne s'applique qu'au système de base et au support de la distribution; rien n'empêche un utilisateur d'installer et d'utiliser lui-même un GCC moderne sur sa boîte FreeBSD.
Une chose à considérer est que FreeBSD utilise actuellement GCC 4.2.1 comme noté dans la réponse ire_and_curses donc les comparaisons de performances ne sont pas de 4.5 ou même 4.6 ne sont pas vraiment pertinentes pour le projet. Par conséquent, les questions que vous devriez vous poser sont:
Quels sont les gains de performance du nouveau Clang par rapport à l'ancien GCC que le projet utilise?
Comment les mêmes binaires compilés dans GCC 4.2.1 se comparent-ils au nouveau Clang?
En raison du passage de GCC à la GPL v3, FreeBSD a été contraint de continuer à utiliser GCC 4.2.1 (GPL v2), qui a été publiée il y a bien longtemps en 2007, et qui est maintenant considérablement dépassé.
Si Clang est à la traîne du CCG actuel mais a encore des années-lumière d'avance sur le CCG mis en œuvre dans le projet, sa décision d'évoluer est bien justifiée et vraiment inspirée.
Même si GCC est GPLv3, les binaires résultants produits par GCC n'ont jamais eu de contrainte de licence. En clair, vous pouvez utiliser GCC pour créer un logiciel sous la licence que vous souhaitez. Même la bibliothèque C fournie avec GCC et incluse dans le binaire est sans licence. http://www.gnu.org/licenses/gcc-exception-faq.html
Section 2 de la GNU GPLv3:
Vous êtes autorisé à propager un travail de code cible formé en combinant la bibliothèque d'exécution avec des modules indépendants, même si une telle propagation violerait autrement les termes de la GPLv3, à condition que tout le code cible ait été généré par des processus de compilation éligibles. Vous pouvez ensuite transmettre une telle combinaison selon les conditions de votre choix , conformément à la licence des modules indépendants.
"Éligible" signifie que la compilation n'implique pas à la fois des logiciels incompatibles avec GCC et GPL. Ce n'est pas une restriction: un logiciel sous licence BSD peut être utilisé dans le processus de construction impliquant GNU GCC.
Comme vous pouvez le voir, contrairement à ce qui a été dit ci-dessus, il n'y a pas [~ # ~] véritable [~ # ~] raison liée à la licence éloignez-vous de GCC car il n'y a pas d'incompatibilité avec l'utilisation de GCC dans FreeBSD.
La véritable raison de ce changement est politique et opportuniste:
- BSD possède sa propre licence qui, philosophiquement, est en concurrence avec la licence GNU Public license (as * ire_and_curses * expliqué ci-dessus),
- CLANG est un nouveau compilateur non GPL initié par un sponsor de FreeBSD qui semble être techniquement équivalent au GCC sous licence GPL (comme décrit ci-dessus par * ire_and_curses *).
Ces faits créent une opportunité pour FreeBSD de s'éloigner de GCC et de s'en débarrasser: ils ne sont en fait pas obligés légalement, car ils pourraient toujours utiliser GCC pour créer des logiciels gratuits ou sous licence BSD, mais ils veulent s'en tenir à la Philosophie "tous les logiciels sous licence BSD".
Je ne suis pas un expert, mais ma compréhension est que Clang/LLVM utilise moins de ressources que GCC et est plus rapide.
http://clang.llvm.org/features.html#performance
Si vous utilisez un environnement dans lequel vous devez créer beaucoup de choses, très souvent, ces performances peuvent se traduire par de réelles économies de coûts et de temps énergétiques. Si c'est réel.