Ce compilateur est disponible pour toutes les variantes*BSD, mais également pour Linux, Mac OS X et Windows. Il est capable de générer du code pour de nombreuses architectures comprenant i386, PowerPC, ARM, ainsi que neuf autres machines un peu moins courantes.
Beaucoup voient en lui une alternative viable à GCC qu'il pourra à terme remplacer. Il est d'ailleurs inclus dans l'arbre des sources de projets comme OpenBSD et NetBSD depuis plus d'un an. En terme de performance, ce petit compilateur est capable de produire des exécutables 15 fois plus rapidement que ceux de GCC (seulement 5 fois plus rapidement si l'on active les tests internes de validité, les « sanity checks »), pour une vitesse d'exécution environ 10% plus lente. Cette relative lenteur s'explique par le fait que PCC ne fait des optimisations que sur l'allocateur de registres (alors que l'on peut en faire à plein d'autres endroits). De nombreuses améliorations sont à faire ou à terminer, c'est pourquoi le projet à besoin de votre aide. Historique
Portable C Compiler a originellement été écrit par Stephen C. Johnson des laboratoires Bell vers la fin des années 70. Il a été le compilateur préféré sur System V et sur les version 4.x de BSD. Il n'a été remplacé par GCC qu'en 1994 avec 4.4BSD.
Depuis 2002, le code source a subi un gros nettoyage et plus de la moitié à été réécrit. Ainsi la version actuellement disponible est une modernisation de ce compilateur.
Plan pour la version 1.0
Les dons permettront de faire avancer grandement le projet. Voici la liste des tâches prévues :
- Amélioration de la conversion vers la forme Static Single Assignment.
SSA est une représentation intermédiaire permettant entre autre de réaliser des optimisations. La conversion des arbres d'expressions d'une fonction en une forme SSA et vice-versa requiert :
- la création d'un graphe de flux de contrôle (CFG) ;
- la construction d'un arbre dominant ;
- le calcul de la frontière de dominance ;
- les fonctions d'insertions phi ;
- la re-numérotation des variables temporaires.
- la création d'un graphe de flux de contrôle (CFG) ;
- Amélioration de la prise en charge des fonctionnalités de la norme C99.
De nos jours, la norme C99 est probablement la norme du C la plus utilisée. Elle a introduit quelques fonctionnalités qui peuvent simplifier la vie des programmeurs mais qui ne sont pas encore disponibles dans PCC :
- amélioration des nombres complexes : prise en charge des types de données _Complex et _Imaginary ;
- amélioration des tableaux dynamiques dans les entêtes/prototypes : la prise en charge des tableaux automatiques à taille variable (variable-length arrays) existe déjà mais pas pour les prototypes de fonctions ;
- amélioration des déclaration abstraite dynamique : prise en charge de la possibilité d'utiliser les déclarateurs abstraits (abstract declarators) partout dans le code.
- amélioration des nombres complexes : prise en charge des types de données _Complex et _Imaginary ;
- Amélioration de la compatibilité avec GCC
Le compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC :
- attribute() : prise en charge de la syntaxe de attribute() et contrôle des extensions couramment utilisée ;
- typeof() : prise en charge du mot clé typeof() ;
- plage de nombres du mot clé case : prise en charge des plages de nombres donnés à l'instruction case ;
- énumération incomplète : prise en charge de la déclaration avancée des enums ;
- champ anonyme dans les structures et unions : prise en charge de l'utilisation des membres anonymes compatible à la fois avec GCC et son utilisation historique.
- attribute() : prise en charge de la syntaxe de attribute() et contrôle des extensions couramment utilisée ;
- Portage de PCC sur l'architecture amd64.
Tout reste à faire pour cette architecture de plus en plus courante :
- mise en œuvre du générateur de code ;
- mise en œuvre du générateur de code FPU (pour les calculs à virgule flottante) ;
- mise en œuvre du générateur de code PIC (utilisé pour charger le code des bibliothèques logicielles).
- mise en œuvre du générateur de code ;
Les dons se font par l'intermédiaire de l'association « BSD Fund » qui fonctionne de la même manière que « Linux Fund ». Elle a pour objectif de financer les projets, événements et initiatives en rapport avec les systèmes BSD.
L'objectif de la campagne de dons de PCC est de 12 000 dollars (soit environ 9 329 euros). L'argent sera versé à Anders Magnusson après que l'ensemble des points ci-dessus aient été complétés.
Aller plus loin
- PCC (45 clics)
- La page des dons sur BSDFund (12 clics)
- GCC (0 clic)
- DLFP : Sortie de GCC 4.3 (10 clics)
- Journal DLFP : Fin de gcc dans les *BSD ? (14 clics)
# Alternative ?
Posté par patrick_g (site web personnel) . Évalué à 9.
Heu...alternative peut-être...mais uniquement si on veut compiler du C !
Pour les autres langages supportés par GCC (C++, Java, Fortran, Ada, Objective-C) elle est ou l'alternative ?
>>> pour une vitesse d'exécution environ 10% plus lente
Ou sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture.
Quand à la motivation du projet PCC il est certain qu'une situation de monopole n'est jamais saine. GCC a beau être un superbe soft il vaut mieux pour le logiciel libre que des alternatives émergent (on pense à LLVM par exemple). PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance.
Je ne peux toutefois m'empêcher de trouver curieuse la justification apportée par Theo de Raadt dans cette interview d'octobre 2007: http://www.thejemreport.com/content/view/369/
Je cite : "What other hurdles remain in replacing GPL-licensed programs in OpenBSD?
TdR: But that's never really been the agenda, see. Some people think we hate GNU code. But the thing is we hate large code, and buggy code that upstream does not maintain. That's the real problem...".
Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).
Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
[^] # Re: Alternative ?
Posté par Victor . Évalué à 7.
Tout comme un objectif de LLVM était de faire un truc un peu plus modulaire (si je ne me trompe pas, je suis pas un pro de tout ces trucs), je pense que PCC va aussi essayé de répondre à cette problématique.
[^] # Re: Alternative ?
Posté par psychoslave__ (site web personnel) . Évalué à 10.
[HS]
Mon premier message écrit tout en bépo sur linufr ! Bon je suis encore loin de ma vitesse de frappe en AZERTY.
[/HS]
[^] # Re: Alternative ?
Posté par patrick_g (site web personnel) . Évalué à 10.
C'est la vérité vraie (même si le mail ou il déclare ça date de 2000):
http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
Y'avait eu une discussion sur LWN ou j'avais aussi posté le lien vers ce mail et il y a des commentaires intéressants:
http://lwn.net/Articles/301135/
[^] # Re: Alternative ?
Posté par Metzgermeister . Évalué à 5.
Je sais bien que Stallman est très attaché à l'aspect éthique du logiciel libre, mais de là empêcher une solution plus pratique et qui rendrait le logiciel meilleur pour de tels motifs... J'imagine que Stallman est aussi opposé aux modules Linux :)
[^] # Re: Alternative ?
Posté par reno . Évalué à 5.
Choquant dans quel sens? Surprenant?
Non, c'est cohérent pour RMS..
Réfléchi à ce qu'a impliqué la création de la license GPL par rapport aux logiciels libres qui existaient déjà sous license BSD, MIT: plutôt que de contribuer aux logiciels libre existant, c'est créer une incompatibilité afin d'avoir une license qui (du point de vue de RMS) défend mieux les droits des utilisateurs.
C'est la même chose ici.
On est d'accord ou pas avec RMS, mais il est assez cohérent dans ses actions d'après ce que j'en sais.
[^] # Re: Alternative ?
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Maintenant je ne sais pas si choisir une architecture logiciel moins bonne techniquement à été un bon choix politique, peut être. Moi je comparais plutôt ça au fait de pousser theorra pour la vidéo sur internet alors que celui-ci est loin d'être la meilleur solution technique.
[^] # Re: Alternative ?
Posté par reno . Évalué à 2.
Sinon pour theora, tu pense à quoi comme meilleur solution technique?
Dirac? Il est très gourmand au niveau CPU donc je ne suis pas convaincu que ce soit une bonne idée de l'utiliser pour diffuser des vidéos sur Internet et les autres formats ont des problèmes de brevets logiciels aux USA.
[^] # Re: Alternative ?
Posté par Zenitram (site web personnel) . Évalué à 3.
H264/AVC, et de loin.
et les autres formats ont des problèmes de brevets logiciels aux USA.
Ce n'est pas technique, donc non éliminatoire pour le poste de meilleure solution technique.
Sinon, ben on fait avec ce qu'on a, soit Theora pour le présent, Dirac pour le futur.
[^] # Re: Alternative ?
Posté par totof2000 . Évalué à 7.
Euh ... C'est certainement ce dont ont besoin de nombreux projets comme les BSD .... Avoir un compilateur qui compile tout et fait le café c'est bien, mais pour la base d'un OS écrit en C, c'est peut-être pas utile ....
Ou sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture.
Fais-la, fais le bench puisque tu sembles aussi sur de toi ...
Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre.
Euh ... OpenBSD a audité/réécrit une grosse partie du code de OpenBSD en ayant pour objectif la sécurité. Faire la même chose pour le compilateur qui génère le code semble bien compliqué pour une "usine à gaz" tel que GCC. Par contre un compilateur plus simple permettrait aux équipes OpenBSD de le maintenir eux-même ou au moins de remonter les problèmes rencontrés plus facilement ..... C'est l'intérêt majeur d'un tel projet .....
Je vois bien les deux compilateurs cohabiter sans problème ... tout au moins pour les BSD .. PCC chargé de compiler le système de base, et GCC s'occuper des logiciels supplémentaires, qui eux ne sont pas forcément écrit en C.
[^] # Re: Alternative ?
Posté par reno . Évalué à 6.
Ahem, en science c'est à celui qui fait une affirmation de la prouver et non pas le contraire..
Affirmer "[PCC fournit] une vitesse d'exécution environ 10% plus lente [que GCC]" sans benchmark: ca n'a pas grande valeur..
J'imagine que ce chiffre n'est pas sorti au hasard, donc il doit y avoir quelque chose derriere pour le justifier.
Cela dit les besoins d'un OS sont très particulier et Linus lui-même rale relativement souvent contre gcc qui casse du code en 'sur-optimisant'.
[^] # Re: Alternative ?
Posté par ErrTu . Évalué à 4.
http://undeadly.org/cgi?action=article&sid=2008110813583(...)
[^] # Re: Alternative ?
Posté par M . Évalué à 2.
> Under which conditions? Which level of optimization are you using for the gcc benchmarks? Which version? 90% of gcc's performance with a register allocator alone is quite a claim.
Yes, it is. I haven't tested it since I wrote the register allocator some years ago, so it may have been against 2.95.
[^] # Re: Alternative ?
Posté par vosgien_ . Évalué à 3.
I used bytebench. Hm, a rerun on some of the passes shows that the difference is not much more against gcc 3.3.5 with -O2:
Test pcc -O gcc -O2 % of gcc performance
dhry2 1197813 1359242 88%
int 168286 186189 90%
float 190144 192564 99%
arithoh 2264451 3354473 67%
short 198920 198930 100%
double 145081 192597 75%
---
Average 87%
The cases where pcc is significantly slower is missing optimizations like strength reduction etc.
[^] # Re: Alternative ?
Posté par M . Évalué à 2.
oui, je parle du bench des 10% plus lent que gcc.
Celui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.
PS : je ne parle même pas du fait que -O2 est utilisé au lieu de -O3.
[^] # Re: Alternative ?
Posté par herodiade . Évalué à 5.
Cette remarque au sujet la version de gcc ne manque pas d'ironie. Il est plus que probable que ragge utilise cette version parce que c'est celle qui est incluse dans OpenBSD pour les architectures i386 et amd64. C'est une vieille version parce qu'ils (les devs. d'OpenBSD) n'arrivent pas à suivre le rythme et à maintenir eux-même les versions plus récentes de gcc (les devs. de gcc ne maintiennent pas le port OpenBSD pour eux). Ce qui explique qu'ils cherchent une porte de secours...
Sinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement, où quelques "low hanging fruits" sont encore à portée de main.
[^] # Re: Alternative ?
Posté par ribwund . Évalué à 2.
C'est avant la réarchitecture de GCC (et c'est vrai que si quand ils disent que le code de GCC est dégueu, c'est du code de GCC3 qu'ils parlent, je les comprends).
[^] # Re: Alternative ?
Posté par patrick_g (site web personnel) . Évalué à 2.
C'est vrai que cela n'est pas ridicule sur ce benchmark.
N'oublions pas toutefois que GCC 3.3.5 est loin, très loin, d'être une version récente. Depuis ce vénérable ancêtre de 2004 il y a quand même eu un paquet de versions de GCC :
GCC 3.3.6
GCC 3.4.0
GCC 3.4.1
GCC 3.4.2
GCC 3.4.3
GCC 3.4.4
GCC 3.4.5
GCC 3.4.6
GCC 4.0.0
GCC 4.0.1
GCC 4.0.2
GCC 4.0.3
GCC 4.0.4
GCC 4.1.0
GCC 4.1.1
GCC 4.1.2
GCC 4.2.0
GCC 4.2.1
GCC 4.2.2
GCC 4.2.3
GCC 4.3.0
GCC 4.3.1
GCC 4.3.2
Et la toute nouvelle version 4.4 est sur le point de sortir. Comparer les perfs de PCC avec GCC 3.3.5 est donc biaisé (mais on est d'accord que c'est la version présente dans l'arbre des ports d'OpenBSD donc c'est ça qui compte pour eux).
[^] # Re: Alternative ?
Posté par beagf (site web personnel) . Évalué à 8.
Quelle quantité d'amélioration y a-t-il dans chaque version que tu cite ? Est-ce que l'équipe de Gcc fais une nouvelle version à chaque correction d'une faute d'orthographe ? Est-ce qu'il y a une nouvelle version à chaque fois que l'amélioration de perf atteint 10% de gain par rapport à la précédente ?
Bref, ce n'est pas parce qu'il y a eu de nombreuse version depuis la 3.3.5 que les perfs sont meilleur. Donc, on a des bench par rapport à la 3.3.5 et ces tout. Pour avoir des infos face au dernières version, il faut là aussi faire des benchs.
[^] # Re: Alternative ?
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Pourquoi ne pas demander un support de TCC dans CompBench ? (c' est un benchmarker de compilation selon scénarios -appli déclarées, etc etc-). Avec le fonctionnement de CompBench, vous auriez un ensemble de résultats pouvant être comparé, entre GCC x.x et TCC, non ?
CompBench :
http://compbench.sourceforge.net/cgi-bin/index.cgi
En plus, c' est le bon moment pour demander une feature comme la prise en charge de PCC
(Peut être même la branche Melt de Gcc ? Voir le compilateur TCC de Mr Bellard)
Cdlt.
[^] # Re: Alternative ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
et
s/voir/comme
désolé
[^] # Re: Alternative ?
Posté par auve . Évalué à 10.
Je ne pense pas qu'on se foute de nous, juste qu'il ne faut pas perdre de vue l'optique selon laquelle ces benchs ont été effectués.
PCC a vocation à remplacer le compilateur de base par défaut d'OpenBSD. Ce dernier fut jusqu'à relativement récemment*, si je ne m'abuse, un GCC 2.95 assez lourdement modifié pour gérer certaines choses, en particulier certaines formes de vérification dynamique servant à contrer les attaques par débordement & co. Je crois que maintenant c'est un 3.3, avec le 2.95 uniquement pour certaines architectures matérielles. Il est donc parfaitement logique et cohérent de comparer avec ces vieilles versions de GCC pour évaluer pragmatiquement l'impact sur OpenBSD.
Par contre, généraliser à « PCC est seulement 10% plus lent que la dernière version de GCC », c'est à mon avis naïf, voire mensonger.
<voyance>Selon moi l'écart va avoir tendance à se creuser, GCC me semblant être en train de décoller dans la recherche académique, et à bouger peut-être un peu plus vite sur certains points (passage au C++ selon la proposition d'Ian Lance Taylor ?). Les effets bénéfiques de la concurrence pure et non faussée :-) ?</voyance>
* : Un GCC plus moderne est évidemment disponible dans les ports.
[^] # Re: Alternative ?
Posté par Étienne . Évalué à 10.
Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
Il me semble avoir lu plusieurs fois des commentaires de Marc Espie se faisant remarquer que seules les architectures x86 et powerpc étaient correctement maintenues et qu'ils avaient régulièrement des problèmes pour les architectures plus exotiques. D'autre part, les dev OpenBSD se plaignent de la difficulté à faire inclure des patchs.
Voir par exemple http://undeadly.org/cgi?action=article&sid=2007091519520(...)
Étienne
[^] # Re: Alternative ?
Posté par herodiade . Évalué à 10.
[...]
> Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
Il apparait que TdR en sait un poil plus long que toi sur les compilos et la façon dont ils sont maintenus. Un boût de phrase, évident mais implicite t'aurait sans doute aidé à comprendre ce dont parle Théo : il n'est pas assez maintenu ... pour les choses qui importent à OpenBSD.
En l'occurrence, OpenBSD se traine sur certaines plateformes un vieux gcc 2.95 (et les autres sont restées en 3.3, d'ailleurs) parce que support par le gcc "upstream" a été délaissé. Le support pour la plateforme OpenBSD est lui aussi, bien entendu, à la charge des devs OpenBSD : les grosses boites qui paient des développeurs à plein temps pour améliorer gcc n'ont que fiche des OpenBSD sur Vax et archis pour bricoleur dinosaures. Le m68k n'est sans doute plus assez corporate. Ces grosses boites font évoluer le logiciel, très vite (ce qui est d'autant plus dur à suivre, du coup), précisément, et l'écart à rattraper pour maintenir les fonctionnalités _qui importent à OpenBSD_ se creuse chaque jour.
Ce mode de fonctionnement est tout à fait justifié de la part de gcc, mais il explique aussi le malaise de certains développeurs qui doivent de facto assurer pendant leurs loisir le maintient d'un code qui change très vite, qui change d'une façon qui ne respecte en rien leurs besoins, un code vieux de 23 ans de patchs accumulés, un code qui est volontairement structuré pour ne pas être modulaire.
[^] # Re: Alternative ?
Posté par patrick_g (site web personnel) . Évalué à -2.
C'est vrai que le marché mondial pour de l'OpenBSD sur du VAX ou du m68k est tellement gigantesque, tellement monstrueux que ça vaut le coup de garder une version 2.95 ;-)
Bon trêve de plaisanterie. TdR veut un compilo simple et qui intègre les modifs du projet OpenBSD. Il est évident que GCC ne réponds pas à ces critères et il est donc légitime de sa part de chercher ailleurs. Tout le monde comprends ça....mais pas besoin de sa part de troller en disant que GCC est un projet qui n'est pas maintenu upstream.
[^] # Re: Alternative ?
Posté par herodiade . Évalué à 10.
Mais bon sang, on parle d'un OS d'amateurs, de gens qui développent pour le plaisir, alors oui, Vax est capital, et ils y consacrent du temps. Tu semble ne pas le croire, mais ça l'est vraiment, pour eux, au moins.
En tout cas parler de "marché", fut-ce au figuré, montre où se niche la confusion. C'est précisément là où se trouve le sel des BSD (et certainement où devait être le fun dans le petit monde de Linux avant 1998 environ) : une petite famille, peu de développeurs, tous sont connus, peu de patchs (on peut suivre les changements), bref des projets à taille humaine ; un engouement pour les vieilles machines, du code pour le plaisir du code (ou pour sa beauté, sa simplicité avant son efficacité, par ex.) comme de l'art pour l'art, ou plutôt de l'artisanat, et vraiment rien de corporate. Pas de "marché". GCC pour sa part est touché par l'excès inverse.
D'ailleurs, cette propriété en soi ça suffit à expliquer ce travail sur PCC (bien que ça ne soit pas la seule raison) : même s'il est probable que ça fasse un compilateur plus lent et moins complet, il y a un certain nombre de développeurs qui ont envie de mettre les mains dans les entrailles d'un compilateur au code clean et à dimension humaine. Juste pour le plaisir du bricolage, de l'amateurisme éclairé.
[^] # Re: Alternative ?
Posté par reno . Évalué à 4.
Ayant (ab)usé de CVS je comprends ce qui les attire: c'était un logiciel ou si tu as corrompu certaines donnée, tu peux lancer un vi et corriger à la main.
Mais ceci dit je considère quand même que c'est un logiciel qui a fait son temps et si j'avais à choisir un logiciel de gestion de configuration j'irais plutôt voir du coté de Mercurial (git m'a l'air compliqué a utiliser) que de CVS..
[^] # Re: Alternative ?
Posté par Metzgermeister . Évalué à 2.
[^] # Re: Alternative ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: Alternative ?
Posté par Patrick Lamaizière (site web personnel) . Évalué à 10.
Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
Gcc a laissé tomber des architectures toujours maintenues dans OpenBSD, de ce point de vue on peut pas dire que gcc est maintenu.
Je t'invite à lire les commentaires de Marc Espie sur gcc.
http://undeadly.org/cgi?action=article&sid=2007091519520(...)
les pixels au peuple !
# pas tout jeune
Posté par Jean-Max Reymond (site web personnel) . Évalué à 6.
[^] # Re: pas tout jeune
Posté par Mathieu Segaud . Évalué à 6.
> dont on dispose maintenant
justement, dans le cas d'un projet comme les *BSD, ce n'est pas anecdotique. Il y a plusieurs architectures à maintenir et à compiler. Pour un même code, le temps de compilation entre gcc3 et gcc4 a pu doubler. Certes on peut arguer du fait que oui, maintenant on a des proco rapides, mais d'une part il n'est pas tjs facile de mettre à jour le matériel à son bon gré (problème de fonds) ni non plus sage: cela permet de cacher un constat médiocre, i.e. doubler à machine égale le temps d'exécution d'une tâche est une régression sévère.
[^] # Re: pas tout jeune
Posté par Larry Cow . Évalué à 10.
Si et seulement si on parle bien de la même tâche. Le fait que GCC4 est plus lent à compiler que GCC3 peut également signifier qu'il fait mieux son travail (code mieux vérifié, mieux optimisé, ...)
[^] # Re: pas tout jeune
Posté par B16F4RV4RD1N . Évalué à 8.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: pas tout jeune
Posté par tanguy_k (site web personnel) . Évalué à 6.
Et c'est super pénible, surtout en C++
Ca ralentit énormément la productivité (processus modification code - compilation - test) et ca donne envie d'utiliser des langages interprétés.
Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial. Rien n'empêche après de fournir un binaire à l'utilisateur compilé avec GCC et toutes les optimisations qui vont avec.
[^] # Re: pas tout jeune
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Tiens, c'est exactement pour ça que je suis passé du C++ au Python :-) Le C++ est quand même un cas particulier avec ses horribles templates qui augmentent considérablement le temps de compilation. D'ailleurs, il me semble que les autotools n'exploitent toujours pas la précompilation des entêtes C++ :-( Quand j'utilise Borland C++ Builder, la précompilation des entêtes faisait passer le temps de compilation de 5/10 minutes à 60 secondes.
[^] # Re: pas tout jeune
Posté par patrick_g (site web personnel) . Évalué à 2.
Pourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0) et à la fin de l'écriture du programme on n'a plus qu'a optimiser à fond (-O3).
[^] # Re: pas tout jeune
Posté par Troy McClure (site web personnel) . Évalué à 4.
[^] # Re: pas tout jeune
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: pas tout jeune
Posté par Troy McClure (site web personnel) . Évalué à 2.
Ensuite pour des projets du genre traitement audio en temps-reel ça repond bien aux contraintes de performance, et actuellement tout l'ecosysteme est à 95% en c++ donc ça reste un choix assez naturel. Après c'est vrai que sur d'autres projets j'aurais un peu plus de mal a dire "seul le c++ répond au cahier des charges"
[^] # Re: pas tout jeune
Posté par psychoslave__ (site web personnel) . Évalué à 0.
[^] # Re: pas tout jeune
Posté par herodiade . Évalué à 5.
Parce que c'est bien trop lent de toutes façons (la différence avec ou sans optims est minimale).
Le projet OpenBSD se fait fort de compiler ses binaires pour toutes les architectures supportées (y compris de _très vieilles archis_) sur la plateforme elle-même. Ce qui évite par ex. de faire comme les devs NetBSD, qui s'aperçoivent parfois des mois après qu'une archi est cassé parce que ça passait bien à la cross-compilation... Et ça permet de stress tester le noyau en cours de développement sur ces architectures : c'est de l'intégration continue, en somme. Évidemment ça marche moins bien quand on a un compilo lent et mal supporté (mal supporté : sur l'archi/plateforme en question, comme tu semble ne pas comprendre...).
[^] # Re: pas tout jeune
Posté par Littleboy . Évalué à 2.
# PCC... déjà pris ce nom
Posté par Patrice FERLET (site web personnel) . Évalué à 2.
http://www.roadsend.com/
Ca me rappelle mes déboire avec le navigateur "flock" donc un exécutable linux existe déjà mais ne sert pas à la même chose :p
[^] # Re: PCC... déjà pris ce nom
Posté par drakkar . Évalué à 1.
Ne serait-ce que l'exécutable /usr/bin/git qui peut venir de deux paquetages différents:
- les outils GNU, puisque là GIT signifie GNU Interactive Tools;
- l'outil de gestion de révisions, cher à Linus, utilisé notamment pour gérer le code du noyau et d'autres projets.
Ça m'a fait un peu bizarre quand j'ai lancé mon premier " git clone ... " et que je me suis fait réprimander. Il m'a fallu un petit instant pour me rendre compte qu'il ne s'agissait pas du logiciel attendu.
J'imagine donc que la méprise est commune, et qu'il existe bien d'autres cas !
[^] # Re: PCC... déjà pris ce nom
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
# PCC concurrent de GCC ?
Posté par Victor STINNER (site web personnel) . Évalué à 8.
http://www.haypocalc.com/blog/index.php/2007/12/03/85-option(...)
PCC n'est plus maintenu depuis longtemps (Theo semble dire l'inverse, que GCC n'est plus maintenu) : ce n'est que récement que PCC renait de ses cendres. Pour moi, c'est plutôt un coup marketing : OpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.
J'avais dressé une liste (sûrement incomplète des compilateurs C libres) :
http://www.haypocalc.com/blog/index.php/2007/10/02/77-compil(...)
Apparement, le seul qui puisse atteindre le niveau de GCC est LLVM. Ce dernier n'est pas spécifique au C, Apple l'utilise déjà pour compiler des shaders (code pour les cartes graphiques). Il sait faire de la compilation à la volée (JIT). Il y a un projet (PyPy) qui l'utilise pour compiler du Python. Bref, rien à voir comparé à la blague qu'est PCC.
[^] # Re: PCC concurrent de GCC ?
Posté par ribwund . Évalué à 4.
Pour une fois que Apple verse du code :)
[^] # Re: PCC concurrent de GCC ?
Posté par psychoslave__ (site web personnel) . Évalué à 6.
Cela pourrait même mettre en avant des problèmes de GCC et permettre de l'améliorer. Les bien fait d'une saine concurence dirait certains. Évidemment il faut une volonté de part et d'autres de coller au standard et pas d'enfermer dans les spécificités. De ce coté là je pense que ça devrait aller non ?
[^] # Re: PCC concurrent de GCC ?
Posté par totof2000 . Évalué à 9.
Non .....
Vu les GNUseries que tu trouves dans les outils GNU qui ne sont pas compatibles avec les standards Unix, j'y crois peu ....
Celà dit ce n'est pas forcément la faute aux outils, mais surtout la façon dont ils sont utilisés .... La portabilité est loin d'être le souci de beaucoup de développeurs de Logiciels Libres.
[^] # Re: PCC concurrent de GCC ?
Posté par vosgien_ . Évalué à 10.
Pour répondre calmement...
Hum, PCC est un compilateur C, soit. Mais de là à oser dire qu'il est un concurrent à GCC, faut pas abuser.
Dans l'article il est parlé d'alternative à GCC au sein du système et pour compiler celui-ci. A quoi cela sert de savoir compiler du fortran, du java, etc. dans la base d'un os ? Pas grand chose.
GCC sait compiler bon nombre de langages, PCC se concentre sur le C, et c'est en cela qu'il peut représenter une alternative à GCC (ragge parle d'ailleurs d'ajouter plus tard le support d'autres langages comme le C++).
OpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.
PCC n'a rien à voir avec OpenBSD ou Theo. C'est un projet commun à tous les BSD et l'association en charge de la collecte des fonds s'occupe de tous les BSD sans préférence... D'ailleurs, ragge, le mainteneur de PCC est l'ancien mainteneur de l'archi VAX de NetBSD...
Bref, rien à voir comparé à la blague qu'est PCC.
Pourquoi être si insultant ? PCC est un compilateur C petit, portable, très rapide et produisant des binaires relativement bonnes.
Du fait de ces avantages et de sa licence il a tout pour intéresser les systèmes BSD qui souhaitent avoir un bon compilateur C (et rien d'autre) pour l'os de base... Alors oui, la route est encore longue et PCC n'avait pas été maintenu depuis des lustres... mais tous les projets libres commencent bien un jour non ? Pourquoi tant de haine ?
[^] # Re: PCC concurrent de GCC ?
Posté par gaston . Évalué à 8.
Parce qu'on est sur trollfr.org, et que dès qu'on peut baver sur du BSD faut pas se priver \o/ ! On connait pas le sujet, donc bavons !
C'est en partie pour ca que je prends de moins en moins de plaisir à lire les commentaires...
[^] # Re: PCC concurrent de GCC ?
Posté par patrick_g (site web personnel) . Évalué à 3.
Nous serions plus qu'heureux que tu proposes de belles dépêches en relation avec le monde BSD. Cela contribuerait à élever le niveau et à faire connaitre le sujet.
[^] # Re: PCC concurrent de GCC ?
Posté par gaston . Évalué à 8.
[^] # Re: PCC concurrent de GCC ?
Posté par Bapt (site web personnel) . Évalué à 4.
[^] # Re: PCC concurrent de GCC ?
Posté par kowalsky . Évalué à 4.
[^] # Re: PCC concurrent de GCC ?
Posté par patrick_g (site web personnel) . Évalué à 3.
J'ai regardé avant d'écrire mon post et c'est parce que j'ai vu que tu avais fait la news d'OpenBSD 3.8 que je me suis dit que tu pouvais continuer au lieu de critiquer.
>>> je laisse ce boulot à d'autres qui ont beaucoup plus de patience et de tact que moi :)
J'ai fais les news OpenBSD 3.9 et OpenBSD 4.0...est-ce à dire que j'ai beaucoup plus de patience et de tact ? Ou bien est-ce parce que ton accusation de baveur anti -BSD à mon encontre est finalement mal fondée ?
[^] # Re: PCC concurrent de GCC ?
Posté par Bapt (site web personnel) . Évalué à 3.
[^] # Re: PCC concurrent de GCC ?
Posté par patrick_g (site web personnel) . Évalué à 0.
[^] # Re: PCC concurrent de GCC ?
Posté par herodiade . Évalué à 5.
[^] # Re: PCC concurrent de GCC ?
Posté par patrick_g (site web personnel) . Évalué à 6.
Faudrait cesser de jouer les calimero et avoir le cuir un peu plus épais !
[^] # Re: PCC concurrent de GCC ?
Posté par patrick_g (site web personnel) . Évalué à 9.
Mais oui. Des baves du style "PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance" n'est ce pas ?
Je dis explicitement que le développement de PCC est souhaitable pour le logiciel libre dans son ensemble mais visiblement tu ne lis que ce que tu veux bien lire.
Je ne sais pas ce qu'ont certains utilisateurs de systèmes BSD mais il semble que dès qu'on émet la moindre réserve on se fait traiter de tous les noms.
[^] # Re: PCC concurrent de GCC ?
Posté par totof2000 . Évalué à -2.
[^] # Re: PCC concurrent de GCC ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Mais en quoi le fait de dire que PCC ne pourra pas remplacer GCC tant qu'il ne supportera pas d'autres langages que le C est un dénigrement ? Pour moi c'est juste le rappel d'un fait.
Si l'utilisateur peut se contenter du C (antérieur à C99) alors PCC est effectivement une alternative, sinon non.
En quoi le fait de dire que l'argument selon lequel GCC ne serait pas maintenu est faux est un dénigrement de PCC ? Pour moi c'est juste le rappel d'un fait. Cet argument du manque de développement upstream ne doit pas être utilisé car il est faux.
En quoi le fait de dire que l'écart de 10% de performances n'est pas soutenu par des benchmarks est un dénigrement ? Pour moi c'est juste le rappel d'un fait. Tant que nous n'aurons pas des benchs comparatifs il est normal et sain d'être quelque peu sceptique au sujet des performances car, de l'aveu même de son mainteneur, PCC n'est pas optimisé.
Dire que je bave systématiquement sur les BSD est absurde. J'ai écrit pas mal de news sur les OS BSD, sur PC-BSD et j'ai même écrit la news sur LLVM 2.2 qui est un compilateur sous licence BSD : http://linuxfr.org//2008/02/18/23723.html
[^] # Re: PCC concurrent de GCC ?
Posté par totof2000 . Évalué à 3.
Heu...alternative peut-être...mais uniquement si on veut compiler du C !
Pour les autres langages supportés par GCC (C++, Java, Fortran, Ada, Objective-C) elle est ou l'alternative ?
La tournure des phrases .... le "!", et la question posée .... J'ai tendance à employer ce genre de tournure quand j'ai affaire à quelqu'un de mauvaise foi ou quand j'ai un abruti en face de moi ....
Ou sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture
La aussi la tournure ..... pas besoin d'insister sur le "J'attends de pied ferme" ...
[^] # Re: PCC concurrent de GCC ?
Posté par vosgien_ . Évalué à 1.
Si tu avais lu la news complètement, tu aurais pu voir que la conformance à la norme C99 est un des principaux objectifs de PCC.
[^] # Re: PCC concurrent de GCC ?
Posté par patrick_g (site web personnel) . Évalué à 0.
[^] # Re: PCC concurrent de GCC ?
Posté par vosgien_ . Évalué à 4.
Campagne de dons pour le compilateur PCC
[^] # Re: PCC concurrent de GCC ?
Posté par kimelto . Évalué à 3.
GCC = `GNU C Compiler`
Apès si les gens de GNU sont pas très cohérents et ont choisis le même sigle pour dire `GNU Compiler Collection` ...
Donc ici on parle du compilateur C ;-)
[^] # Re: PCC concurrent de GCC ?
Posté par bubar🦥 (Mastodon) . Évalué à 5.
Il y a quelques années, pour un lecteur, GCUsquad était ce groupe dont on osait à peine s' approcher, dont on se délectait des news du site, on était ravi quant DragonflyBSD a eu sa tite mascotte sur le iste... Bref un endroit clean, marrant, carré.
Regarde aujourdui ce qu' est devenu GCUsquad : le fameux ton des news n' est plus inventif, il n' est devenu qu' un remplaçant au manque d' imagination des nouveaux rédacteurs. Même pas une marque de fabrique tant c' est mal usité aujourdhui.
Bref les petits nouveaux chez GCUsquad ne valent pas mieux que les petits nouveaux ailleurs en ce moment. Avec la particularité du "j'me'la'pete'je'suis'gcu". Bref GCUsquad a chuté sévère... A cause certainement d' un récente trop grande ouverture ala "viendez maintenant, plus besoin d' être un guru pour être à la gcu" ben voilà... ils les ont, leurs nouveaux... du genre à porter le t-shirt OpenBSD toute l' année, mais même pas avoir un *bsd installé chez eux... ou alors dans une vm.
Parcequ' a l' origine ils se sont ouverts pour des types comme moi, juste des users, voilà le résultat...
Donc faut pas généraliser, Patrick_g :
certains utilisateurs de systèmes BSD mais il semble que dès qu'on émet la moindre réserve on se fait traiter de tous les noms CERTAINS et pas tous, effectivement :D
HS : Bref, tout le monde semble victime de la "démocratisation" (humhum). Là où ça fait le plus 'mal', ce n' est pas pour une gcu qui baisse en niveau (au regard des users qui se prennent pas pour) mais c' est plutôt dans notre presse (Diamonds Edition) où on matraque le lecteur à coup de photos d' écrans avec toujours la même distribution, toujours le même bureau, et toujours le même wm. Chez Diamond, on ne démocratise même plus, on matraque...
(gcu et diamond dans le même commentaire, ça va moinsser sévère...)
[^] # Re: PCC concurrent de GCC ?
Posté par FRLinux (site web personnel) . Évalué à 4.
[^] # Re: PCC concurrent de GCC ?
Posté par ribwund . Évalué à 1.
Personnellement c'est juste le gâchis qui m'énerve, y'a un compilateur moderne sous licence BSD qui marche bien, pourquoi réinventer la roue ? Quand on voit l'énergie qu'il faut investir pour faire un compilo (optimisant et multi-plateforme, sinon c'est sûr c'est beaucoup plus simple)...
[^] # Re: PCC concurrent de GCC ?
Posté par totof2000 . Évalué à 3.
[^] # Re: PCC concurrent de GCC ?
Posté par ribwund . Évalué à 3.
Je pense serieusement que le niveau de complexité d'un compilateur est du niveau de la complexité d'un noyau. C'est pas n'importe quel outil...
[^] # Re: PCC concurrent de GCC ?
Posté par totof2000 . Évalué à 2.
Non.
Les raisons pur créer un nouveau noyau peuvent être multiples ... C'est comme si tu disais que forker un projet libre parce que ne convenant pas aux besoins est une auvaise idée ...
Pour le noyau, l'intéret peut être que les projets exoistants ne répondent pas à un besoin précis, et que adapter l'existant au besoin coute autant, voir plus que redévelopper pour son propre besoin. L'intéet de développer un noyau peut être d'apprendre les concepts de base du développement de noyau pour oarticiper ensuite à un projet plus évolué (prendre en route un projet existant sans connaitre les principes fondamentaux sous jacents est quasi impossible).
Et puis dans ce cas ils ne partent ps de zero, ils partent d'un outil qui était autrefois utilisé dans s les BSD .... donc qui est un minimum connu ...
.
[^] # Re: PCC concurrent de GCC ?
Posté par ribwund . Évalué à 2.
(disclaimer: je fais de la recherche en compilation)
Mouais, on peut toujours partir d'un jouet... Mais je persiste à penser que c'est généralement une perte de temps, il y a tellement d'optims à implementer... De plus PCC n'est pas vraiment un compilateur moderne (il aurait fallu commencer par faire du SSA et partir d'un vrai compilo cross-plateforme).
C'est comme les gens qui font tous des VM ou des JIT dans leur coins alors qu'il y a tellement à faire...
[^] # Re: PCC concurrent de GCC ?
Posté par Bapt (site web personnel) . Évalué à 6.
Mais n'est craintes beaucoup de dev BSD sont intéressés par LLVM (en particulier chez FreeBSD).
[^] # Re: PCC concurrent de GCC ?
Posté par kowalsky . Évalué à 6.
Personnellement c'est juste le gâchis qui m'énerve, y'a un compilateur moderne sous licence BSD qui marche bien, pourquoi réinventer la roue ?
Oula, doucement...! De quelle gachis parles tu ?
On t'a forcer à coder sur PCC ?
Non, alors ne dis pas n'importe quoi. Les gars font ce qu'ils veulent, c'est du logiciel libre tu sais.
[^] # Re: PCC concurrent de GCC ?
Posté par ribwund . Évalué à 1.
[^] # Re: PCC concurrent de GCC ?
Posté par Metzgermeister . Évalué à 4.
Ah tiens non, « ça a pas les mêmes objectifs ». Same here.
La communauté de toute façon ne peut pas être uniforme et du même avis, il y a forcément des divisions, et de toute façon, la sélection naturelle fera le reste : si PCC devient une alternative viable pour compiler le basesys, il sera adopté, sinon GCC restera, il n'y a pas de mal. Au contraire, on peut lire le joyeux Theo qui trolle à fond et c'est rigolo. :-)
[^] # Re: PCC concurrent de GCC ?
Posté par abramov_MS . Évalué à 3.
[^] # Re: PCC concurrent de GCC ?
Posté par Metzgermeister . Évalué à 2.
[^] # Re: PCC concurrent de GCC ?
Posté par Victor STINNER (site web personnel) . Évalué à -1.
Interview de Theo au sujet de PCC (et GCC) :
http://www.thejemreport.com/content/view/369/
Extrait : « we hate large code, and buggy code that upstream does not maintain (...) gcc gets about 5-6% slower every release, has new bugs, generates crappy code, and drives us nuts »
Critique de GCC par Marc Espie du projet OpenBSD :
http://undeadly.org/cgi?action=article&sid=2007091519520(...)
Tu vois pas le rapport ?
[^] # Re: PCC concurrent de GCC ?
Posté par vosgien_ . Évalué à 5.
Le développement récent de PCC n'a rien à voir avec OpenBSD, mais est la volonté de ragge (à l'origine de NetBSD) qui en avait besoin.
Au sein d'OpenBSD, un développeur (otto) s'est intéressé aux qualités du compilo, et après des discussions avec d'autres devs et Theo, il a été importé. Ca a également été le cas pour NetBSD.
Ce que je trouve vraiment stupide, s'est d'affirmer des choses au sujet d'OpenBSD qui sont fausses. Un coup marketing d'OpenBSD ?? Tu crois que ragge a été payé par Theo pour relancer PCC et puis donne des pots de vins aux autres BSD pour travailler dessus ?? Arrêtons les blagues... PCC n'a pas attendu OpenBSD...
# Historique : y a quand même des fautes qui passent mal pour un journal
Posté par totof2000 . Évalué à 6.
Le compilateur GCC a introduit des extensions au language langage C
Celle-là je la supporte pas ....
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Jean-Max Reymond (site web personnel) . Évalué à 2.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par patrick_g (site web personnel) . Évalué à 1.
J'aurai jamais du me lancer là-dedans, je sens que ça va être sans fin.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par totof2000 . Évalué à 2.
En fait j'en ai pas relevé beaucoup ... Les deux que je mentionne sont celles qui m'ont le plus choqué .... surtout le "u" de langage que je déteste à un point, je ne sais pas pourquoi. Y a-t-il un docteur dans la salle pour m'aider ?
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par grafit . Évalué à 1.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Larry Cow . Évalué à 4.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 4.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par totof2000 . Évalué à 2.
Comme je disais plus haut, le fait d'utiliser des extnsions qu'apporte un outil n'est pas mal en soi, mais il faudrait toujours penser et développer en conséquence : distinguer les éléments qui utilisent ces extensions et développer son code pour que quelqu'un qui ne les utilise pas puisse facilement modifier le code en conséquence.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 2.
Si ces extensions ne sont pas indépendantes de l'outil et réutilisable dans un autre outil pour garder l'interopérabilité, pourquoi pas. Si par contre ce sont des extensions "propriétaires", c'est mal (TM). Surtout des extensions à un langage aussi important que le C.
Bon j'ai pas vérifier mais je suppose que ces extensions sont facilement désactivables à la compilation, voir idéalement ne pas sont activées par défaut.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par reno . Évalué à 2.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Mouns (site web personnel) . Évalué à 10.
on rale pour le manque de respect des standards et les extensions propriétaire plus ou moins non documenté au niveau interoperabilité ( à ne pas confondre avec la doc utilisateur ), mais dès qu'il s'agit de la FSF et du projet GNU, ca ne dérange quasiment plus personne.
donc le monopole du projet GNU qui tient au niveau des distribs essentiellement autour de la GNUlibc ... justifie à lui seul l'impositiion monopolistique d'un GNU/Linux. Et que l'on ne me sorte pas que tout repose sur du GNU dans linux ! sinon de la meme maniere, on devrait parler d'un GNU/OpenBSD dès qu'il y a besoin d'installer une partie du projet GNU pour faire fonctionner des trucs comme the Gimp, GNOME, OOo, ...
Stop à la connerie, et admettons enfin que la situation du projet GNU est un monopole intellectuel qui techniquement ne repose que sur une dépendance à GNU make, GCC et la GNUlibc.
le noyau linux est un des rares gros projet qui peut etre compiler sans GCC.
Mais combien de projet utilise des extensions non standardisée et surtout sans spécification autre que du source et un bout de doc utilisateur ?
Dans la même veine :
Ca ne dérange personne que l'on répete que tout ce qui est libre doit etre compatible avec la GNU GPL ?
sachant que une GPL2 strict n'est pas compatible avec la GPL 3 strict ... cela ne dérange personne non plus.
Donc la liberté c'est d'être compatible avec la FSF ? de respecter les choix de la FSF ? de penser comme la FSF ?
drole de liberté qu'une liberté completement fermée et dependante du bon vouloir d'une organisation dirigée par un seul homme.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par totof2000 . Évalué à 1.
Bienvenue dans la religion FSF ....
Stop à la connerie, et admettons enfin que la situation du projet GNU est un monopole intellectuel qui techniquement ne repose que sur une dépendance à GNU make, GCC et la GNUlibc.
C'est exact mais pas seumlement. Techniquement, GCC est loin d'être à la ramasse ... ce qui explique pourquoi il est également utilisé pour générer les divers BSD.
Ca ne dérange personne que l'on répete que tout ce qui est libre doit etre compatible avec la GNU GPL ?
Si, les développeurs BSD par exemple ....
Donc la liberté c'est d'être compatible avec la FSF ? de respecter les choix de la FSF ? de penser comme la FSF ?
Bienvenue dans la religion FSF (bis).
drole de liberté qu'une liberté completement fermée et dependante du bon vouloir d'une organisation dirigée par un seul homme.
Note que comme beaucoup de religions, ce n'est pas le fondateur ou le noyau d'origine qui pose problème, mais une partie de ceux qui ensuite adhèrent au concept. En soi, le fait qu'ils pensent avoir raison et que les autres ont tort n'est pas gênant, par contre ce qui est gênant ce sont leurs pratiques pour imposer leur point de vue et refus d'admetttre que les autres peuvent penser différemment.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 6.
On se dit qu'il y a vraiment une volonté d'enfermer tout le monde dans un même modèle. Ce modèle a beau offrir une vision philosophique intéressante, je trouve ca vraiment navrant de voir qu'elle conduit à mal concevoir des logiciels, voir à pratiquer une forme d'obfuscation (faire du monolithique pour faire chier), ce qui va complètement à l'encontre pour moi de la diffusion libre du savoir que veut pourtant promouvoir la FSF.
En gros on applique ce qu'on critique : vérouillage de l'interopérabilité, extensions propriétaires, limiter la réutilisation et le pire, c'est qu'on les justifie avec la même philosophie qu'on utilise pour critiquer les autres modèles de logiciels.
Heuresement, le modèle offre suffisament de libertés pour sortir de cette impasse. Vivement que certains utilisateurs "pragmatiques" forkent ces composants essentiels pour les rendre pérennes.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par patrick_g (site web personnel) . Évalué à 7.
Y'a quand même un bel avantage technique qui est sorti de la position de Stallman : Apple a contribué au support d'Objective-C dans GCC alors que si il était possible d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain") que le support d'Objective-C serait resté purement dans le giron d'Apple.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par ribwund . Évalué à 3.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 2.
Et ? ca aurait été quoi le problème du moment que le résultat était sous GPL ? La FSF doit avoir le monopole sur le dev de GCC comme l'équipe du kernel doit avoir le monopole sur le dev des drivers ?
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par patrick_g (site web personnel) . Évalué à 2.
C'est ça que veut éviter Stallman : le fait pour une entreprise de garder des plugins proprios qu'on peut brancher sur GCC.
Stallman préfère, et on le comprends, que le code contribué soit sous licence libre et pour cela il oblige à contribuer directement à GCC.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 3.
Oué enfin si le backend GCC est sous GPL et mis sous forme de bibliothèque, tout ce qui lui est lié doit également être sous GPL. Je vois mal Apple ne pas diffuser sa toolchain Objective-C, donc le frontend serait forcement diffusé et sous GPL.
nan parcque si on poursuit le raisonnement, on fait plus de bibliothèque, on fait un gros bouzin monolithique qu'on appelerait "GNULinux.deb"
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par shbrol . Évalué à 1.
Un backend GCC en bibliotheque sous GPL, ca apporte pas grand chose : on peut construire avec un generateur de binaire qui prendra en entree des fichiers intermediaires provenant de l'analyseur de code. En fonction du niveau d'integration de la bibliotheque, le source de ce generateur fera une dizaine de lignes, et bien sur il sera sous GPL.
Et je garde mon analyseur de code tout proprietaire pas beau, qui produit des fichiers intermediaires sans passer par le backend, parce que le format intermediaire est documente.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par reno . Évalué à 0.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Guillaume Knispel . Évalué à 1.
C'est ton interprétation.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Guillaume Knispel . Évalué à 1.
Arrête de raconter n'importe quoi.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par herodiade . Évalué à 6.
> Apple a contribué au support d'Objective-C dans GCC alors que si il était possible
> d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain")
> que le support d'Objective-C serait resté purement dans le giron d'Apple.
C'est marrant que prenne cet exemple, parce que Apple, qui est le principal contributeur de LLVM (qu'ils "donnent" gratuitement donc), a montré qu'on peux faire un compilateur modulaire, sous licence BSD, et auquel des boites peuvent contribuer sans radinerie mesquine. LLVM est le parfait contre-exemple de la théorie politique de GCC.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Guillaume Knispel . Évalué à 3.
Les extensions de GCC (comme celles de la majorité des compilateurs C, y compris visual C) sont bien documentées, bien identifiées en tant qu'extension et facile à repérer.
Alors si vous chercher juste un pretexte pour taper sur la FSF, cherchez ailleurs.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 1.
Mais on s'en fou que ce soit bien documenté et facile à trouver, le fait est que le code source qui les utilise ne respecte pas le standard C, et à ce titre aura peu de chance d'être compatible avec un autre compilateur : bref ca va à l'encontre de l'interopérabilité et ca créé une dépendance entre le code source et l'outil (le compilo en l'occurence).
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Gof (site web personnel) . Évalué à 2.
#if defined __GNUC__
/* utilisation des extentions
#endif
Et avec les #define qui vont bien on peut rendre tout ça assez joli.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Gof (site web personnel) . Évalué à 2.
(en considérant biensur que le site reste fonctionnel avec les autres navigateur)
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Etpuis si il faut commencer à gérer les spécificités de chaque parseur, le code peut que devenir plus grouik et moins maintenable. C'est même tout l'intérêt d'une norme/d'un standard.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par TImaniac (site web personnel) . Évalué à 5.
Et les extensions elles servent à quoi si au final tu proposes une implémentation basée sur les standards ? Mon petit doigt me dit que la plupart des programmes utilisant les extensions proprios de GCC ne sont pas compatibles avec d'autres compilateurs parcqu'ils utilisent justement ces extensions pour se simplifier la vie, pas pour proposer une "meilleur expérience utilisateur".
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Guillaume Knispel . Évalué à 2.
Sans compter ceux qui utilisent des extensions parce que... ils n'ont pas le choix... AHHHHH MAIS QU'ELLE HORREUR !
Code un OS en C ISO 99 et reviens nous parler après.
Ou au minimum explique nous comment on fait de l'attribute packed (ou l'équivalent du compilateur XYZ, cette extension existe a peu près dans tous les compilateurs, et rien que pour ça elle mériterait d'être standardisé j'en conviens, mais en attendant on est bien obligé d'utiliser l'extension) dans un programme écrit en ISO C 99 strict ; on cast en char * et on fait les chargements non alignés soit-même avec du code de psychopathe ? super la maintenabilité. De plus la norme fait assez peu d'hypothèse sur la représentation des entiers ou des flottants, donc en fait ç'est quasi impossible sans recopier la mémoire pour l'aligner puis faire un chargement classique : super les performances.
De toute manière ça se voit que tu n'as pas lu la norme, vu qu'elle n'a rien contre les extensions cette fameuse norme -- et en fait elle est carrément formulée pour ne pas gêner les extensions et autres constructions non portables (parce que justement le C est principalement adapté pour coder des OS, ce qui est une activité qui consiste à écrire du code intrinsèquement non portable...).
Bref devant toutes ces considérations passionnantes, je résumerais ma pensée en disant : va faire sérieusement du C (pendant genre 1 an minimum à temps plein, mais 3/4 ans ça serait quand même mieux, et dans des domaines bas niveau parce que ça rime généralement plus à rien d'en faire dans un autre domaine en 2008) et reviens nous parler après.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Zenitram (site web personnel) . Évalué à 1.
Ca, on est d'accord : il y a une norme C et C++, donc mettre par défaut les extensions GNU c'est de la grosse connerie. Je suis le premier à râler contre les projets GCC-only.
Ca ne dérange personne que l'on répete que tout ce qui est libre doit etre compatible avec la GNU GPL ?
Ca, beaucoup moins d'accord : faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme. Et je trouve quand même très pratique de pouvoir mélanger des projets grâce à cette "norme" de fait.
Autant ta première affirmation tient du fait qu'il y a une norme à respecter, autant la deuxième va juste provoquer la dispersion dans le libre, ce dont le libre n'a absolument pas besoin.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Antoine . Évalué à 0.
La norme existe, c'est la Free Software Definition :
http://www.gnu.org/philosophy/free-sw.html
qui est équivalente dans les faits avec l'Open Source Definition :
http://www.opensource.org/docs/definition.php
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Zenitram (site web personnel) . Évalué à 2.
Je sais qu'un programme à la norme ANSI C ou C++ compilera sur tout compilateur à la norme.
Je sais aussi qu'un projet ayant une licence qui respecte les liens que tu as fourni ne sera pas forcement compatible avec une autre licence qui respecte aussi les liens que tu as fourni.
Tu ne proposes donc pas une norme, puisque 2 licences respectant tes documents ne sont pas forcement compatibles.
Tu ne proposes donc rien d'utile pour la compatibilité. "Être compatible GPL" propose à défaut un minimum de compatibilité entre les projets.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Antoine . Évalué à 2.
Je ne savais pas que "respecter une norme" impliquait que tout doit être compatible avec tout.
J'imagine donc qu'il suffit que deux programmes soient écrits selon la norme ANSI C pour avoir des APIs compatibles l'une avec l'autre. C'est magique, ça simplifie la vie.
Ce qui est ridicule dans ton commentaire plus haut, c'est quand tu dis « faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme » en faisant allusion à la GPL. Or la norme de la FSF pour les licences libres, ce n'est pas la GPL mais bien la Free Software Definition.
# Pourquoi remplacer GCC
Posté par blobmaster . Évalué à 4.
Bonjour,
Pourquoi remplacer GCC ?
Je pose la question en toute innocence.
J'ai vu qu'il y avait déjà des éléments de réponse dans les commentaires plus haut mais....
Y-a-t'il plein de raisons que je ne soupçonne pas ?
Innocement,
blobmaster.
[^] # Re: Pourquoi remplacer GCC
Posté par narke . Évalué à 5.
[^] # Re: Pourquoi remplacer GCC
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -3.
[^] # Re: Pourquoi remplacer GCC
Posté par cougnafou . Évalué à 2.
[^] # Re: Pourquoi remplacer GCC
Posté par ouin . Évalué à 3.
Les projets *BSD et GNU n'ont pas les mêmes buts ni les mêmes besoins et encore moins les mêmes contraintes.
Les gens de GNU ont leur compilateurs qu'ils développent comme bon leur semble.
Si les personnes des différents *BSD veulent une fonctionnalité en particuliers ils peuvent soit envoyer des patchs pour GCC, soit créer un fork, soit créer leur propre compilateur.
La première solution pose un gros problème d'indépendance: Les patchs ne seront appliqués qu'au bon vouloir des mainteneurs de GCC qui passent déjà leur temps à travailler pour atteindre leurs objectifs.
La création d'un forks pose pas mal de problèmes de maintenance, en particulier dans le cas d'une usine à gaz comme GCC. J'imagine que la licence en est un autre.
Même si la dernière solution et la plus lourde en terme de moyen, c'est aussi la plus souple: Les projets *BSD auront leur propre compilateur qu'ils pourront faire évoluer selon leurs propres besoins. Tout simplement.
# Si ce n'était pas la licence...
Posté par Steph . Évalué à -5.
Ce n'est pas un troll, mais l'idée que je puisse donner de l'argent à un projet qui pourrait être pillé légalement par une entreprise, me dérange...
[^] # Re: Si ce n'était pas la licence...
Posté par totof2000 . Évalué à 8.
[^] # Re: Si ce n'était pas la licence...
Posté par totof2000 . Évalué à 3.
[^] # Re: Si ce n'était pas la licence...
Posté par Steph . Évalué à -5.
La licence BSD le permet, si je ne m'abuse.
Maintenant j'aimerai que tu m'expliques avec quelle certitude tu peux affirmer que personne ne le fait...
[^] # Re: Si ce n'était pas la licence...
Posté par Metzgermeister . Évalué à 3.
[^] # Re: Si ce n'était pas la licence...
Posté par Steph . Évalué à -1.
Celui qui choisit la licence BSD pour ses projets, fait à la fois un don à la communauté, mais également aux entreprises susceptibles de l'utiliser.
Je ne suis simplement pas prêt à faire la même chose avec mon argent, c'est tout.
[^] # Re: Si ce n'était pas la licence...
Posté par Zenitram (site web personnel) . Évalué à 2.
ca ne te permet pas de dire qu'une entreprise peut piller. Piller, c'est aller à l'encontre de la volonté de la personne pillée, ce qui n'est absolument pas le cas de la licence BSD.
Alors vire ce mot de ton vocabulaire concernant la licence BSD, et respecte-la : on ne te demande pas de donner de l'argent obligatoirement pour un projet BSD ni d'aimer les projets BSD, mais de respecter ceux qui font un autre choix que le tiens.
(sans compter que comme la BSD est libre! Le libre n'impose pas d'interdire le proprio)
[^] # Re: Si ce n'était pas la licence...
Posté par Steph . Évalué à -1.
Donc j'ai parfaitement le droit d'utiliser ce vocabulaire, car c'est de mon éventuelle contribution dont il est question ici.
Mais où as tu vu que je ne respectais pas le choix de l'auteur ?!
L'auteur, tout comme moi, fait ce qu'il veut.
J'ai simplement parlé de mon choix à moi, et expliqué pourquoi je ne voulais pas donner MON argent.
[^] # Re: Si ce n'était pas la licence...
Posté par totof2000 . Évalué à 4.
Non ce ne serait pas du PILLAGE dans la mesure ou les conditions sont clairement définies au départ ...
Petite analogie : considères-tu qu'une banque te pille lorsque le taux d'intéret d'un prêt à taux variabla augmente, alors que lors de la souscription de ce prêt, il était clairement mentionné que c'était un prêt à taux variable ?
La c'est la même chose ....
[^] # Re: Si ce n'était pas la licence...
Posté par Steph . Évalué à -2.
Va poser la question aux victimes des subprimes US, qui se sont retrouvées à la rue...
Tu pourras toujours leur expliqué "Oui mais pourtant c'était clairement mentionné..."
Blague à part l'analogie est foireuse, car ma démarche pour un don n'a absolument rien à voir avec l'obtention d'un prêt où je paye pour un service.
Quand je fais un don à un projet GPL je le fais pour la communauté, car je sais que l'utilisation du code sera équitable. Si je ne le fais pas pour un projet BSD, c'est parce que je sais que ça peut ne pas être le cas.
C'est comme faire un don à une ONG où tu saurais par avance qu'une partie des fonds pourraient être détournés.
Je respecte parfaitement la volonté de l'auteur, qui lui ne voit pas les choses de cette manière puisqu'il a choisit sciemment la licence en conséquence.
Ma générosité à moi s'arrête simplement à l'espace communautaire, lorsque la licence garantit l'équité.
[^] # A propose des banques.
Posté par Zenitram (site web personnel) . Évalué à 4.
C'est ce que je leur dirai, oui.
Ils ont joué avec le feu, ils prennent que ce qu'ils ont "acheté".
Certes, les banques ont manqué de leur devoir de conseil et ont prêté à n'importe qui, mais la faute est aussi aux gens qui se sont dit que ça monterai toujours, que consommer ce qu'on a pas gagné c'est bien, qui n'ont pas fait gaffe aux scénarios possibles.
J'ai un prêt à taux variable, et j'en suis content : je l'ai fait en connaissance de cause, je l'ai capé (+1%), j'ai subit l'augmentation mais elle était prévue dans mon budget (c'est écrit noir sur blanc dans le contrat : le taux suit l'Euribor), l'augmentation s'est arrêtée au capé, point. Je pouvais prendre un capé +2 moins cher, mais +2 me faisait peur (pour mon budget). La où d'autres auraient dit "c'est moins cher, je prend", j'ai regardé le risque (trop grand).
Il est un peu trop facile de mettre tout sur le dos des banques :
- Elles prêtent pas : des méchantes qui ne font pas confiance au consommateur
- Elles prêtent : des méchantes qui abusent des gens.
Dans tous les cas, l'accusation fait que le fautif sera toujours l'autre. Et ben non, il y a une grosse part de fautifs dans ceux qui ont pris l'emprunt.
Ma générosité à moi s'arrête simplement à l'espace communautaire, lorsque la licence garantit l'équité.
C'est mieux dit, et c'est totalement compréhensible. C'est ton droit.
Il n'y a pas besoin de traiter d'autres de noms qu'ils ne méritent pas pour donner ton opinion...
[^] # Re: Si ce n'était pas la licence...
Posté par totof2000 . Évalué à 5.
# Besoins d'OpenBSD
Posté par Étienne . Évalué à 9.
Je pense que la l'incompréhension du choix de PCC par l'équipe d'OpenBSD vient du fait que l'on ne prend pas en compte toutes les exigences du projet, je vais essayer de les synthétiser.
L'objectif premier est de pouvoir compiler tout le système de base d'OpenBSD, ce changement ne concerne donc pas l'intégralité des ports mais seulement ceux du système de base, et ceci bien sûr pour toutes les architectures gérées par OpenBSD. Ce qui veut dire qu'il faut que ce compilateur :
- puisse compiler suffisamment rapidement et sans consommation excessive de mémoire pour compiler sur les machines peut puissantes. (voir à ce sujet http://www.onlamp.com/pub/a/bsd/2004/03/18/marc_espie.html la réponse à la question What is the plan for gcc3 introduction? (bas de page))
- puisse compiler tout le système de base, dont le compilateur, ce qui signifie qu'il doit pouvoir se bootstraper
- gère correctement l'intégralité des architectures cibles d'OpenBSD. Correctement signifie que la maintenance d'une architecture doit rester le plus simple possible et ne soit pas cassée sans arrêt au grès des commits.
- Ce qui est très important est que les devs puissent facilement faire intégrer leurs modifications, ce qui ne semble pas être le cas sur gcc qui est essentiellement géré par les distributions commerciales Linux et par Apple dont les objectifs ne sont pas toujours conciliables avec ceux d'OpenBSD.
- Sans oublier que les devs OpenBSD sont assez portés sur la sécurité et donc sur la simplicité ce qui, et je ne pense pas qu'on me donnera tord sur ce point, n'est pas la force de gcc.
Étienne
[^] # Re: Besoins d'OpenBSD
Posté par patrick_g (site web personnel) . Évalué à 1.
En revanche les 2 dernières raisons sont parfaitement légitimes et je comprends pourquoi les devs d'OpenBSD cherchent une alternative à GCC
[^] # Re: Besoins d'OpenBSD
Posté par vosgien_ . Évalué à 6.
Je te rappel que dans le post original, Etienne parlait du besoin de compiler rapidement. Tu considères que la vitesse d'un compilateur, c'est être capable de cross-compiler sur des machines puissantes quand sur l'archi cible c'est trop lent ?
Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).
J'ai chez moi une vieille Sun SparcClassic, qui met environ une semaine pour compiler le système complet. Je ne parle même pas de mon VAX... Si tu étais développeur, tu comprendrais que passer d'un compilo qui met une semaine pour compiler un OS à un autre qui met 5 fois moins de temps, c'est un TRES GROS avantage.
Et puis quant à la portabilité, gcc l'est oui, mais c'est en comptant sur le fait qu'il soit catastrophique sur les archis autres que i386/amd64/PPC. Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ? Si c'était le cas, tu verrais que gcc est très loin d'être ce petit bijou que tu crois être...
[^] # Re: Besoins d'OpenBSD
Posté par patrick_g (site web personnel) . Évalué à 3.
Effectivement c'est un bon argument et on comprends la nécessité d'un compilateur rapide. Personnellement ça m'énerverai de constater que mon binaire x86 est tout lent parce qu'il a été généré par un compilo rapide de façon à être compatible VAX....mais bon c'est un choix. Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?
>>> Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ?
Excuse-moi de ne prendre en compte que les logiciels libres. Je sais c'est bizarre mais c'est comme ça.
[^] # Re: Besoins d'OpenBSD
Posté par kowalsky . Évalué à 3.
Et les gars qui le font tourner sur VAX le font souvent par plaisir.
[^] # Re: Besoins d'OpenBSD
Posté par vosgien_ . Évalué à 5.
Ce que tu dis montre clairement que tu n'es pas développeur et que tes remarques sont sans aucun fondement.
Pour toi un compilateur rapide produit du mauvais code ? C'est faux... PCC produit du bon code avec seulement très peu d'optimisations...
Pour toi un bon binaire i386 voudrait dire un binaire vax lent et vice versa ? C'est complètement incohérent.
Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?
Non je ne le pense pas... par contre ce dont je suis sûr c'est que le fait de maintenir des archis lentes et complètement dépassées depuis des lustres comme le vax permet à OpenBSD de régulièrement découvrir des bugs qui ne seraient jamais remontés sur des plateformes rapides.
[^] # Re: Besoins d'OpenBSD
Posté par M . Évalué à 3.
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 ?
[^] # Re: Besoins d'OpenBSD
Posté par vosgien_ . Évalué à 2.
http://linuxfr.org/2006/11/07/21588.html
[^] # Re: Besoins d'OpenBSD
Posté par M . Évalué à 3.
J'ai juste vu une allusion au fait que les binaire cross compilé n'avait pas été testé (et c'était révélé foireux)...
[^] # Re: Besoins d'OpenBSD
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est une excuse plus que foireuse la!
PS : je ne pose aucune opinion sur le choix de PCC ou GCC ça pue ça gère pas les archis exotiques et ça rame, je me prononce juste sur l'excuse plus que foireuse qui peut être avancée pour "devoir" compiler sur une machine qui rame.
[^] # Re: Besoins d'OpenBSD
Posté par djano . Évalué à 2.
Le seul moment ou OpenBSD utilise la cross compilation, c'est pour initier un nouveau port. Ensuite ils font de la compilation native.
[^] # Re: Besoins d'OpenBSD
Posté par reno . Évalué à 3.
Mais c'est un test nécéssaire pour la validation pas pour le developpement ou la, tu auras le résultat bien plus rapidement en cross-compilant ce qui diminue notablement le nombre de compilation native nécéssaire..
[^] # Re: Besoins d'OpenBSD
Posté par herodiade . É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, ...
[^] # Re: Besoins d'OpenBSD
Posté par Cyril . Évalué à 0.
Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).
Un binaire cross-compilé est moins "bon" qu'un binaire compilé nativement ?
Tu m'apprends qqchose ... comment ça se fait ? tu aurais un lien ou une explication ?
[^] # Re: Besoins d'OpenBSD
Posté par reno . Évalué à 4.
Hein? Et pourquoi les binaires générés par cross-compilation serait de qualité inférieure à ceux généré par compilation 'native'??
On peut préférer compiler de manière native car c'est plus simple à mettre en oeuvre ok, mais la "qualité" des binaires..
Soit dit en passant, ayant travaillé sur des projets C++ qui mettaient *plusieurs heures* a compiler (sans optimisation), je fais partie de ceux qui pensent que la vitesse de compilation est importante, oui.
D'ailleur c'est un argument *pour* la cross-compilation pour les vieilles machines: entre un PC avec un ou plusieurs CPU multi-GHz avec des giga de RAM et un VAX, j'aurais tendance à penser que gcc sur le PC sera plus rapide à compiler que pcc sur le VAX..
[^] # Re: Besoins d'OpenBSD
Posté par M . Évalué à -1.
Si l'objectif est de compiler le système de base, alors pourquoi s'embêter a ajouter une compatibilité gcc [1]. Je pense pas que le code de base soit du code GNU venant de Linux...
Surtout que ca va pas trop dans le sens de la simplicité.
[1]
Amélioration de la compatibilité avec GCC
Le compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC
[^] # Re: Besoins d'OpenBSD
Posté par Romeo . Évalué à 8.
La team OpenBSD ne développe pas PCC ! OpenBSD est juste très intéressé par le produit afin de remplacer GCC.
Donc la team PCC implémente si elle veut la compatibilité GCC.
# Qu'est-ce qui foire dans GCC ?
Posté par cpradier_ . Évalué à 4.
C'est souvent que j'en entends parler, souvent en mal, mais dans la pratique, j'en ai toujours été content pour l'usage que j'en ai fait et je sais que la plupart des logiciels libres que je chéris sont compilés avec ; donc, qu'est-ce qui cloche?
Est-ce un problème de design, un problème d'implémentation, un problème de communauté qui implémente ? Est-ce que c'est un mauvais compromis efficacité/propreté ? Un mauvais compromis features/maintenance ?
Désolé pour mon newbisme.
[^] # Re: Qu'est-ce qui foire dans GCC ?
Posté par djano . Évalué à 10.
- GCC n'est pas assez modulaire (séparation nette entre la partie de GCC qui lit le fichier source et crée un arbre du programme, entre la partie intermédiaire qui transforme cet arbre en un autre, entre la partie de GCC qui génère l'assembleur pour l'architecture cible), ce qui le rend difficile a maintenir.
- critique des développeurs d'OpenBSD: GCC abandonne régulièrement des architectures (qu'OpenBSD supporte toujours) et GCC ne marche pas correctement sur les architectures moins courantes (qui ne sont pas x86, x86-64, itanium, power)
- GCC est lent pour compiler, ce qui est gênant pour OpenBSD car ils compilent OpenBSD en continu et en natif sur de vieilles architectures / machines.
- ce n'est pas faire un tort de dire des développeurs d'OpenBSD qu'ils sont des maniaques de la qualité (revues de codes permanentes, durcissement du système en intégrant le plus possible de technologies pour sécuriser le système) et ils disposent d'un compilateur GCC extrêmement modifié pour intégrer des technologies de sécurité, d'où l'intérêt pour eux de disposer d'un compilateur extrêmement simple dont ils peuvent facilement revoir le code (le code de GCC est énorme).
- enfin d'après OpenBSD, le travail avec les développeurs GCC n'est pas facile car ils n'intègrent pas les patches soumis par OpenBSD ou globalement ont des vues très différentes sur les objectifs d'un compilateur. Pour résumer: OpenBSD voient le compilateur comme une opportunité de renforcer les contrôles du code et est donc un élément essentiel pour sécuriser tout le système,alors que les développeurs GCC sont à la recherche maximale de performance du binaire compilé.
[^] # Re: Qu'est-ce qui foire dans GCC ?
Posté par totof2000 . Évalué à 2.
Ils devraient réécrire OpenBSD en ADA ... :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.