Il serait 5 à 10 fois plus rapide que gcc et produirait des binaires suffisament optimisé.
Il a été importé [ http://undeadly.org/cgi?action=article&sid=2007091519520(...) ] dans OpenBSD [ http://marc.info/?l=openbsd-cvs&m=118988004013923&w=(...) ] et NetBSD [ http://mail-index.netbsd.org/pkgsrc-changes/2007/09/15/0009.(...) ].
Otto Moerbeek ayant nottament écris sur la mailling list de pcc
Of course the road is still long, but things really look promising
Serais-ce la fin du dernier gros morceau de code GPL chez les *BSD ?
# llvm
Posté par ribwund . Évalué à 9.
(Il n'y a même pas encore de SSA dans pcc...)
Sinon a leur place j'aurais utilisé clang (front end C d'apple, licence BSD) +llvm (backend BSD, maintenu entre autre par apple). clang demande encore du travail avant d'etre utilisable (mais en attendant on peut utiliser gcc en back end), par contre llvm est bien plus avancé et il produit des optimisations très efficaces.
[^] # Re: llvm
Posté par galactikboulay . Évalué à 7.
[^] # Re: llvm
Posté par ribwund . Évalué à 5.
Sinon c'est pas comme si un compilateur c'était un des logiciels les plus compliqués à écrire, en tout cas visiblement y'a plein de gens qui aiment tout refaire :)
[^] # Re: llvm
Posté par lasher . Évalué à 2.
[^] # Re: llvm
Posté par ribwund . Évalué à 1.
Ensuite le phi c'est toujours le truc qui fait chier quand on fait un algo sur SSA (la copie est parallèle, le use est dans le bloc précedent, etc).
Sinon construire SSA c'est vraiment trivial, si il arrive pas à le faire c'est que sa representation intermédiaire est à chier, le plus dur c'est de minimiser le nombre de phi sans que la construction prenne trop de temps.
[^] # Re: llvm
Posté par Gabriel Linder . Évalué à 2.
Moi j'appelle ça du "travail en cours".
[^] # Re: llvm
Posté par ribwund . Évalué à 5.
Sérieux quand on voit le buzz que peut avoir ce truc qui est a mille lieux de la plupart des compilos académiques (qui sont encore loin des compilos de productions), c'est à se demander si les experts d'un domaine peuvent encore encore contre balancer la "foule" du web.
Encore désolé, mais je viens de telecharger les sources et la c'est juste risible. J'ai rien contre pcc, c'est un bon projet de licence ou de master pour apprendre comment est fait un compilo mais c'est tout sauf une avancée technologique.
(En plus si j'ai bien compris ce que vienne de faire NetBSD et OpenBSD, ils viennent de forker le projet en l'important chacun dans leur cvs, donc ca risque d'avancer encore moins)
[^] # Re: llvm
Posté par galactikboulay . Évalué à 4.
[^] # Re: llvm
Posté par ribwund . Évalué à 3.
Sinon je trouve llvm très facile d'accès pour comprendre comment marche un backend optimisant. (et clang étant en developpement si des gens veulent faire joujou avec un parser tout neuf, ils peuvent se faire plaisir)
[^] # Re: llvm
Posté par herodiade . Évalué à 5.
D'un autre coté, si j'ai bien compris, le fait qu'il soit très simple et propre est précisément la raison de l'intérêt qu'il suscite. D'une façon générale, il est courant de voir des développeurs BSD réaffirmer leur attachement à la simplicité et la petite taille du code. Nonobstant cette simplicité, il semble que pcc sache déjà compiler (presque) tout le userland de NetBSD/i386 (et produise des binaires à peine 6 à 8% plus gros que ceux produits par gcc, ce qui n'est pas si mal à ce stade infantile de non-optimisations).
Et cet aspect est bel et bien un but du compilateur, tel qu'indiqué sur le site de PCC section « Goal » : « the intention is to write a C99 compiler while still keeping it small, simple, fast and understandable ». Preuve que la sophistication n'est pas toujours (ou pas pour tous) le critère d'ingénierie déterminant, s'agissant d'évaluer l'intérêt d'un logiciel.
> (En plus si j'ai bien compris ce que vienne de faire NetBSD et OpenBSD, ils viennent de forker le projet en l'important chacun dans leur cvs, donc ca risque d'avancer encore moins)
Tu a mal compris, donc.
NetBSD l'a simplement inclus dans pkgsrc (approximativement, pour rapprocher ça de quelque chose que connaissent les linuxien, ils en ont fait un package pour NetBSD).
Et OpenBSD l'a importé dans son cvs comme ils font avec tout les logiciels qu'ils veulent inclure dans le système de base (où re-travailler à partir de là). C'est leur façon de faire, je pense qu'ils trouvent cette méthode plus pratique, mais ce ne sont pas des forks : même les projets qui acceptent toutes les modifs d'OpenBSD upstream (par ex. Sendmail ou Sudo) sont inclus de la sorte dans leur cvs. Il faut garder en tête, lorsqu'on vient du monde Linux, que les *BSD ont une approche plus centrée sur le code source / le cvs (par opposition aux distributions Linux courantes, souvent plus orientées packages / bugzilla).
Bref, ça ne les empêche pas de re-synchroniser régulièrement leur copie des sources, et d'envoyer leurs modifications upstream.
En l'occurence, vous pouvez aisément voir qu'ils travaillent collaborativement, en lisant ce qui se passe sur la mailing-list de pcc. ML dont les archives viennent d'êtres incluses dans MARC, pour info : http://marc.info/?l=pcc-list&r=1&b=200709&w=2
Archive et collaboration qui me rappelle que, si on peut fortement s'inquiéter des problèmes sociaux causés par un compilo qui compilerai trop vite ( http://xkcd.com/303/ ), il ne faut pas bouder le plaisir de trouver un nouveau terrain où de nombreux devs NetBSD et OpenBSD peuvent se foutre sur la gueule collaborer publiquement. Ce qui nous offrira sans doute de superbes coups de hache dans les gencives débats pour les soirées d'un hiver qui vient à grands pas ! :)
[^] # Re: llvm
Posté par ribwund . Évalué à 5.
> (presque) tout le userland de NetBSD/i386 (et produise des binaires
> à peine 6 à 8% plus gros que ceux produits par gcc, ce qui n'est pas
> si mal à ce stade infantile de non-optimisations).
compiler l'userland est un objectif, ils en sont loin...
> Et cet aspect est bel et bien un but du compilateur, tel qu'indiqué sur
> le site de PCC section « Goal » : « the intention is to write a C99
> compiler while still keeping it small, simple, fast and understandable
> ». Preuve que la sophistication n'est pas toujours (ou pas pour tous)
> le critère d'ingénierie déterminant, s'agissant d'évaluer l'intérêt d'un
> logiciel.
gcc est particulier à cause de Stallman qui ne veut surtout pas que le compilo ait 2 passes bien séparées. Il reste moultes compilos qui sont propres et bien plus avancés. Le buzz qui l'accompagne est ridicule (et je ne pense pas que c'était l'effet voulu par les gens qui l'ont importé dans *BSD et par upstream).
[^] # Re: llvm
Posté par NickNolte . Évalué à 3.
[^] # Re: llvm
Posté par A0cC0Fk . Évalué à 2.
[^] # Re: llvm
Posté par ribwund . Évalué à 4.
C'etait un des buts de clang de pouvoir analyser très rapidement le code pour les IDE.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# La rapidité ne suffit pas
Posté par vincent LECOQ (site web personnel) . Évalué à 8.
est il multi archi ?
le code généré assure t il un niveau de sécurité suffisant ? (piles etc ...)
et surement d'autres auxquelles je pense pas, je suis pas expert.
[^] # Re: La rapidité ne suffit pas
Posté par kowalsky . Évalué à 6.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fin de gcc dans les *BSD
Posté par kowalsky . Évalué à 7.
[^] # Re: Fin de gcc dans les *BSD
Posté par Gniarf . Évalué à -3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fin de gcc dans les *BSD
Posté par IsNotGood . Évalué à 0.
- à faire plaisir à des développeurs. Si c'est leur truc, il n'y a rien à redire.
- permettre aux fanatiques BSD de dire "HAHA ! on s'en torche de GNU et de sa (L)GPL tyranique, on a un compilateur ultra-plus-mieux-bien que ce tout pourri et archi-lent de gcc.
En passant, gcc se bootstrappe. Pour compiler gcc, on commence par compiler un mini-gcc (qui ne fait que compilateur C, n'est pas cross-plateforme, n'est pas optimisé, etc) et ce dernier est utilisé pour compiler gcc. Ça doit être un poil plus compliqué car je crois qu'il y a stage1 stage2 et final.
J'ai rien contre pcc, mais j'ai rien pour.
[^] # Re: Fin de gcc dans les *BSD
Posté par totof2000 . Évalué à 3.
[ ZAP ]
- a pouvoir distribuer un ensemble avec licence cohérente ?
Personnellement ça me gène pas de devoir utiliser un compilo spécifique pour le sys tème de base. D'ailleurs c'est aujourd'hui le cas: le système de base se compile avec une version précise de GCC ... donc que ce soit GCC ou un autre, peu importe.
[^] # Re: Fin de gcc dans les *BSD
Posté par M . Évalué à 4.
Ha pourtant je croyais que c'était un compilo des années 70. Les develo avaient utilisé IPOT ?
Au fait pcc se compare comment par rapport à tcc ?
[^] # Re: Fin de gcc dans les *BSD
Posté par lasher . Évalué à 1.
[^] # Re: Fin de gcc dans les *BSD
Posté par IsNotGood . Évalué à 1.
Juré, c'est une horreur. Certains se tapent la tête contre les murs, d'autres se font des saignées, etc...
[^] # Re: Fin de gcc dans les *BSD
Posté par zul (site web personnel) . Évalué à 5.
tcc n'est tellement pas maintenu qu'il existe un "bug de securité" connu depuis Février 2006 et toujours pas corrigé dans une release ...(http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-0635).
Sinon la GPL c'est du tout bon .... pour les avocats :). Pour le reste, cela reste à prouver ...
[^] # Re: Fin de gcc dans les *BSD
Posté par IsNotGood . Évalué à -1.
La BSD c'est bon pour les brevets et les brevet c'est tout bon pour les avocats.
[^] # Re: Fin de gcc dans les *BSD
Posté par vjm . Évalué à 4.
# Re:
Posté par IsNotGood . Évalué à 3.
Visual C++ est aussi très rapide pour compiler (probablement 4 à 6 fois plus rapide que gcc).
Pour le reste il n'est pas du niveau de gcc. Je boose actuellement avec Visual C++ (consigne du boss), ben c'est presque une daube à côté de gcc.
Que Visual C++ soit plus rapide que gcc, ne lui donne aucun charme de plus. Si à l'avenir je peux éviter Visual C++, je l'éviterai.
[^] # Re: Re:
Posté par nullisimo . Évalué à 6.
Un compilo qui va "seulement" 2 fois plus vite que gcc a au moins le charme de compiler un OS complet en 2 fois moins de temps. Surtout quand il faut tester plus d'une dizaine d'archis.
C'est aussi pour ca qu'il est important pour un projet consequent de compiler rapidement, meme si le binaire final n'est pas super optimise, au moins le code a passe le test du "make word".
[^] # Re: Re:
Posté par IsNotGood . Évalué à 3.
Quand tu es développeur (et pas seulement un gentoo lover), tu ne passes pas ton temps à compiler des OS. Tu compiles ton code et il y a make pour compiler que ce qui est nécessaire. Make peut aussi compiler en parallèle (option -j) pour profiter d'un dual/quad core/cpu. Dans ce contexte, la vitesse de gcc est largement bonne.
Je suivais la mailing devel Fedora. Les rebuilds de tout l'OS (dit mass rebuild chez Fedora) sont très rares (un par an à cause d'un changement de version majeur de gcc). Pour F8 ça a été exceptionnel, il y a eu 2 mass rebuild (le premier a utilisé un gcc buggé). Les mass rebuild sont fait en une voire deux journées et pour 4 architectures. Il me faut préciser que Fedora utilise un cluster pour les compilations. Les développeurs Fedora ne font pas des "make world" histoire pour pourrir la planète, il récupère les binaires fait par Fedora.
> C'est aussi pour ca qu'il est important pour un projet consequent de compiler rapidement
Tu veux dire que les *BSD sont des OS gras ?
> au moins le code a passe le test du "make word".
J'en ai des frissons dans le dos.
[^] # Re: Re:
Posté par nullisimo . Évalué à 4.
C'est sur lorsque tu modifies netcat c'est pas la meme chose que modifier le code du routing, UFS ou autres changements intrusifs.
C'est fallacieux de comparer un BSD a fedora. C'est pas du tout la meme contrainte.
[^] # Re: Re:
Posté par IsNotGood . Évalué à -2.
Ben tu le fais rarement. Sinon il y a un bug de conception. De plus il y a la libc entre le noyau et les applis et la libc supporte les versions (on peut donc avoir plusieurs versions d'une API).
Un OS qui demande de tout recompiler toutes les semaines est un OS qui sucks grave de chez grave.
> il faut _toujours_ tout recompiler.
Non.
> que modifier le code du routing, UFS
Dans ce cas tu recompiles le noyau et c'est l'affaire de 10 ou 20 minutes.
> C'est fallacieux de comparer un BSD a fedora.
Ouais, BSD c'est naze, il faut tout recompiler toutes les semaines.
[^] # Re: Re:
Posté par GTof . Évalué à 1.
Quant à comparer Fedora et BSD, j'suis pas un expert dans les deux mais c'est clairement pas les mêmes buts. Pour le citer qu'OpenBSD et NetBSD, l'un se voulant une forteresse imprenable et l'autre voulant tourner même sur les grilles pains, et Fédora qui se veut le plus user friendly (ce qui ne veut pas dire que les BSD ne se veulent pas userfriendly !) il y a tout un monde.
[^] # Re: Re:
Posté par Anonyme . Évalué à 2.
[^] # Re: Re:
Posté par Frédéric COIFFIER . Évalué à 2.
Il y a donc eu 2 possibilités : continuer d'utiliser l'ancienne version de la libstdc++ ou utiliser la nouvelle. Sachant que dans le cas d'un soft utilisant plusieurs librairies, il est impératif que ce soft et ces librairies utilisent la même version de la libstdc++.
Bref, tôt ou tard, il a fallu recompiler toutes les applis/libs utilisant le C++ (ce qui est loin d'être la totalité de la distribution...).
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: Re:
Posté par benja . Évalué à 1.
Enfin bon là c'est sensé être fini avec gcc 4.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Où tu as lu ça ?
Je ne crois pas les développeurs assez cons pour dire "jamais".
[^] # Re: Re:
Posté par Ph Husson (site web personnel) . Évalué à 2.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Notons que la compatibilité sur tous les gcc 4 n'est pas assurée. Par exemple ce qui est compilé avec Fedora 5 ne peut tourner sur Fedora 4. Ce n'est pas un problème de version de librairie mais de compilateur/édition de lien. Mais ce n'est pas un problème car pratiquement personne ne l'a remarqué :-)
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
Des trolleurs dlfp ou les développeurs gcc ?
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 8.
The main point of the GCC 3.2 release is to have a relatively stable and common C++ ABI for GNU/Linux and BSD usage, following the documentation at http://www.codesourcery.com/cxx-abi/
[^] # Re: Re:
Posté par IsNotGood . Évalué à -2.
En passant, Linus Torvalds (himself) utiliser une Fedora. Les changements intrusifs il connait et il ne recompile pas tout tout les matins (Fedora n'est pas Gentoo).
Linus Torvalds est un "plouc" car il ne fait pas de "make word" ?
[^] # Re: Re:
Posté par nullisimo . Évalué à 3.
Je n'ai jamais dit ca. Mais la aussi ce n'est pas la meme contrainte kernel != OS
Mais on va prendre des exemples concrets.
geom_journal sous FreeBSD:
En plus du module geom pour la journalisation, il a fallu modifier pas mal d'outils userland (newfs, tunefs, mount, fsck etc...) a cause du changement de structures, ajouter BIO_FLUSH dans le VFS et d'autre. Pour cela il faut s'assurer que ca compile partout et correctement. Certes, on ne compile pas tout a chaque fois, mais a chaque changement important, il faut s'assurer que ca fonctionne.
Sans compter que dans ce cas la, l'endianness entre en jeu.
Idem pour le routing. Il faut modifier le code kernel + route + la libc + pf + ce qui en depend (opsfd et openbgpd par ex).
[^] # Re: Re:
Posté par IsNotGood . Évalué à -1.
> geom_journal sous FreeBSD:
Certe, mais c'est changé tout les combiens ?
Tous les 3 mois ou tous les ans ?
Es-ce intéressant d'utliser et de développer un compilo "bas de gamme" qui va vite uniquement pour ça ?
De plus ses programmes se compilent vite. Ils sont très petits et même si tu en as une dixaine, c'est l'affaire de 10 minutes (c'est le temps pour la bécane, pour toi ça risque d'être plus long (récupérer les sources, ./configure, installation, etc...)).
C'est quasi sans intérêt. De plus il faut voir la contre partie. Un compilo qui fait moins de vérification que gcc, qui n'est pas cross-plateform, qui n'est pas "renforcé" (controle de débordement), etc, etc...
C'est très bien de faire un "make word" pour voir si tout est cohérent. On peut trouver des bugs etc...
Mais les développeurs qui font ça sont rares. En tout cas, il a autre chose à foutre que ça.
Je dis ça sans le moindre mépris, mais ce n'est pas un boulot de développeur, c'est un boulot de testeur (et j'ai beaucoup fait de tests et j'ai beaucoup de respect pour les testeurs, il faut du talent pour être un bon testeur). Dans le cas de Fedora, il y a des bécanes qui sont affectées à ça avec des procédures automatiques, un scheduler pour plannifier les tests, etc...
Au "petit matin" un mail est envoyé sur la mailing devel et les développeurs regardent ce qui les concernes.
En passant, Fedora utilise moch ce qui permet avec une bécane de compiler un programme pour FC4, FC5, FC6, F7, pour i386 pour amd64, etc.
Tu ne lance pas à moch à chaque fois que tu change une ligne de ton code, mais lorsque tu veux diffuser et t'assurer de la qualité du code (es-ce qu'il compile partout ? sur toute les architectures ? il y a-t-il des fichiers en conflit avec d'autres paquets, etc).
[^] # Re: Re:
Posté par Victor . Évalué à 2.
le but de l'inclusion d'un nouveau compilateur dans openbsd n'est pas ce que tu décris et même le contraire sur certains points
(et j'ai la flemme de les recopier ici :)
[^] # Re: Re:
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Ben, quand tu compiles du code genere' par du code, tu peux te retrouver avec un gros bouzin. J'ai du code qui met plus de 30 minutes a compiler *un seul fichier* (et d'ailleurs, GCC plante souvent sur ce genre de donnees). Et la, vu le code genere, ben, j'ai beau avoir un 16 coeurs, ca m'aide pas... (Et non, on peut pas trivialement generer le code dans plusieurs fichiers)
[^] # Re: Re:
Posté par thedidouille . Évalué à 3.
Par exemple, une méthode avec de nombreux objets, créés sur la stack, visible dans l'intégralité de la méthode, et de nombreux return. Le compilateur doit générer du code pour détruire les objets avant chaque return, ce qui génère un executable énorme et long à compiler.
[^] # Re: Re:
Posté par lasher . Évalué à 3.
Je connais au moins un domaine où la compilation peut prendre un temps pas possible : le calcul haute performance.
Un code scientifique, comportant de nombreuses indirections de tableaux (inévitables, car usant de maillages adaptatifs et de matrices creuses, qui intrinsèquement nécessitent ce genre de structures de données), avec pourtant le maximum de code dont le comportement est statiquement connu à la compilation (parce que programmé en FORTRAN 77 et donc pas de risque d'aliasing, etc), ça peut mettre dans les 45-60 minutes à compiler. Bon ok, le fait que le compilateur voie plein d'opportunités d'optimisation peut clairement jouer, mais la complexité du code est la principale raison de la lenteur de compilation.
Ici donc, pas d'objet, du bête code, à peine mieux que de l'assembleur (bon ok, j'exagère un chouilla).
Par contre, si on parle « presqu'objet », parlons des templates, qui de par leur côté totalement statique fait que les temps de compilation s'allongent, s'allongent ...
Enfin, là on parle de code C, et effectivement, gcc est clairement beaucoup plus lent qu'avant, alors qu'il a relativement peu de choses à analyser (comparé à du code C++).
[^] # Re: Re:
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Avec gcc, un Makefile correct et des fichiers sur nfs, cela va à une vitesse raisonable.
Bref, la vitesse est toute relative et peut fortement dépendre de ton environnement.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 5.
[^] # Re: Re:
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Alors que sous UNIX, j'ai toujours travaillé sur des partages NFS sans jamais avoir eu l'impression que gcc ou nag ou icc était lent. Comme je développe à 99% sous linux, pour moi gcc, c'est que du bonheur ;-)
[^] # Re: Re:
Posté par GeneralZod . Évalué à 1.
Après, je plussois isNotGood, je préfére un compilo aussi strict, respectueux des normes et ubiquitaire que l'est GCC, à un compilo plus rapide bogué et avec un support des normes incomplet. Quitte à comparer GCC à un autre compilateur, autant le comparer à ICC.
[^] # Re: Re:
Posté par briaeros007 . Évalué à 1.
Enfin niveau warning, gcc est loins derrière icc quand meme.
(Comment ca je parle pas de vc++ ? et alors ?)
[^] # Re: Re:
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Re:
Posté par briaeros007 . Évalué à 1.
En outre
Il y a peut etre plus de bruit, mais gcc ne sort pas tout , loin de la. Et quant tu fait du multi archi, tu est content de faire au moins une passe avec le plus de recommandation possible.
Ensuite bien entendu, à toi de vérifier si ca correspond à quelque chose.
En somme je prefere, pour un avertissement, un truc qui fait que des faux positifs, plutot qu'un truc qui fait des faux négatifs et des faux positifs.
Bien entendu le mode warning de icc c'est simplement pour faire des tests, pas pour dvp tous les jours (alors que les warnings de gcc si).
enfin c'est juste ma préférence perso aussi.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
J'ai du code qui compile sous Windows et Linux, et sous Linux (gcc) la compilation est beaucoup plus lente. Mais je m'en fous.
> je préfére un compilo aussi strict, respectueux des normes et ubiquitaire que l'est GCC, à un compilo plus rapide bogué et avec un support des normes incomplet.
VC++ c'est "pire". Il y a des cas (certe complexes) où VC++ perd le type d'un pointeur.
Par exemple :
class CToto : public virtual CTiti, public virtual CTutu {}
CToto * ptoto = new CToto ;
CTiti * ptiti = ptoto ; // plantage avec VC++ alors que ça roule avec gcc. Un dynamic_cast n'arrange rien (il est d'ailleur sans intérêt ici normalement).
VC++ m'a donné des cauchemards. J'avais finit de coder (3 mois de développement), j'étais content de ma hiérarchie d'object "et tout". Je compile: OK. J'exécute : explosion dans tous les coins. Je "porte" sous Linux/gcc, ça marche comme un charme. Ça m'a pris presque deux semaines pour voir que c'était un bug de VC++. Ça m'a pris une semaines pour réorganiser mon code afin qu'il tourne avec VC++. Donc : 3 semaines de perdu. Et vraiment perdu. Si le compilateur est lent, je peux boire un café, discuter, bosser sur autre chose, etc...
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 3.
class Bob
{
public:
Bob() {c=0;}
virtual int Get() {return c;}
private:
int c;
};
class Foo
{
public:
Foo() {d=1;}
virtual int GetFoo() {return d;}
private:
int d;
};
class Bar : public virtual Bob, public virtual Foo
{
public:
Bar() {};
virtual int GetValue() {return GetFoo();}
};
int __cdecl wmain(int argc, WCHAR *argv[])
{
Bar* NewVal=new Bar;
Bob* Cast=NewVal;
printf("%d\n",Cast->Get());
return 0;
}
Affichage : 0
Bref, ton exemple marche tres bien sous VC++
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
> class Bar : public virtual Bob, public virtual Foo
Tes virtual ne servent à rien dans ton exemple.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 3.
Sinon, ca m'interesserait d'avoir une reproduction du probleme.
(pour les public virtual, le but etait simplement de recopier ton code)
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Voilà ce qui ne marchait pas (une petite partie des entêtes) :
class CMixerBmpD3D : public virtual CBmpD3DDesc {
virtual ... = 0 ;
}
class CMixerBmpD3DSurf : public virtual CMixerBmpD3D {
}
class CMixerBmpD3DTex : public virtual CMixerBmpD3D {
}
class CMixerShot : public virtual CShotDesc, public virtual CMixerBmpD3D {
int entier_CMxierShot ;
virtual ... = 0 ;
void fonction_CMixerShot() {
entier_CMixerShot++ ;
}
class CMixerShotSurf : public virtual CMixerShot, public virtual CMixerBmpD3DSurf {
}
class CMixerShotTex : public virtual CMixerShot, public virtual CMixerBmpD3DTex {
}
Ce qui ne marchait était par exemple :
CMixerShotTex * pTex = new CMixerShotTex ;
CMixerShot * pShot = pTex ;
pShot->fonction_CMixerShot() ; // plantage.
Il n'y a pas forcément plantage à l'appel de la fonction mais plantage lors de "entier_CMixerShot++". Un affichage de "*this" dans le débuggeur donne du n'importe quoi alors que je suis dans une fonction membre ! C'est définitivement une erreur du compilateur.
Autre problème :
CMixerShotTex * pTex = new CMixerShotTex ;
CMixerShot * pShot = dynamic_cast<CMixerShot *>(pTex) ;
Le dynamic_cast n'est pas nécessaire. Mais si je l'utilise, pShot est égal à NULL. C'est encore définitivement une erreur du compilateur.
Autre problème :
CMixerShotTex * pTex = new CMixerShotTex ;
f(pTex) ;
f(CMixerShot * pShot) {
CMixerShotTex * pTex = dynamic_cast<CMixerShotTex *>(pShot) ; // retourne NULL alors que c'est un CMixerShotTex *
}
Pour régler le problème, j'ai viré CMixerShot (j'ai déplacé des données/fonctions) et tout regroupé dans CMixerBmpD3D.
> T'es sur que le probleme vient du compilo
Oui, j'ai vu une page web qui en parle mais je ne l'ai plus. Parfois VC++ n'arrive pas à déterminer le type d'un object.
Les "public virtual" sont nécessaires car il y a des données en commun entre CShotDesc et CMixerBmpD3D entre autre.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Le dynamic_cast déclenche une exception __non_rtti_object (ou un truc dans ce goût) alors que c'est compilé avec /GR (stupidement non par défaut dans le compilateur VC++, ce qui ne respecte pas le standard ISO...).
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 2.
CMixerShotTex * pTex = new CMixerShotTex ;
CMixerShot * pShot = pTex ;
pShot->fonction_CMixerShot() ; // plantage.
Il me faudrait voir le code pour confirmer, mais je suis 99.999% sur que le probleme est dans ton code ou du a qqe chose de bien complique.
Ce dont tu parles ici c'est de l'heritage de base, appeler une fonction de la classe parente, j'ai pondu assez de cas identiques depuis des annees (ainsi que des milliers d'autres softs compiles en C++ dans VC++) pour savoir qu'un cas banal comme cela fonctionne sans aucun probleme.
[^] # Re: Re:
Posté par Ontologia (site web personnel) . Évalué à 1.
Les spécialistes du C++ dans la boite ont conclu à un bug du compilateur (VC98).
A la décharge de krosoft (dont le dernier logiciel dépourvu de bug que j'ai connu était le BASIC 128 sur TO9), C++ est un langage horrible(ment complexe) et ça doit pas être facile.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Re:
Posté par Troy McClure (site web personnel) . Évalué à 6.
[^] # Re: Re:
Posté par Ontologia (site web personnel) . Évalué à 5.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
C'est vraiment casse couille.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Désolé, mais le code est propriétaire :-(
J'avais fait un fichier .cpp minimum pour reproduire le bug (savoir spécifiquement ce qui ne marchait pas) mais j'ai foutu ce fichier à la poubelle. C'est ce fichier qui marchait nickel avec gcc et qui plantait toujours VC++. La vrai appli n'a pas été porté sous Linux (c'est quasi impossible).
Si tu vires tous les "public virtual", ça semble marcher sous VC++. Mais je n'ai plus ce que je veux et plein de duplication de donné très difficile à gérer. Donc ça semble marcher par j'ai fait peu de tests pour ce cas.
Autre problème avec VC++, je voulais un "constructeur virtuel". Un truc dans ce goût :
CMixerBmpD3D::Clone() = 0;
CMixerBmpD3DTex::Clone() ;
CMixerShot::Clone() = 0;
CMixerShotTex::Clone() ;
CMixerShotTex * pTex = ... ; // <= C'est un CMixerShotTex
f(pTex) ;
f(CMixerBmpD3D * pBmpD3D) {
CMixerBmpD3D * p = pBmpD3D->Clone() ; // Ici avec VC++ appel de CMixerBmpD3DTex::Clone() et non CMixerShotTex::Clone().
}
Marche nickel avec gcc, sucks avec VC++.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 1.
Si non, alors il est tout a fait normal que ca ne marche pas. Que la fonction ait le meme nom ne signifie pas que ces methodes sont identiques et heritent entre elles.
Si oui, alors je suis 100% sur que ton truc marche sous VStudio, c'est le b-a-b-a de l'heritage ca et je l'ai assez fait (sans parler du fait que Firefox, OO, ... qui compilent sous VC++ sous Windows le font surement aussi) pour savoir que ca marche parfaitement.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 4.
Ton probleme il me semble c'est que ton CMixerShotText derive de CMixerShot directement ET de CMixerBmpD3D (heritage multiple). Hors ces 2 classes derivent d'un ancetre commun.
Resultat il y a ambiguite entre les methodes vu que ces 2 classes ont des methodes identiques.
C'est un probleme classique de design et connu : http://www.parashift.com/c++-faq-lite/multiple-inheritance.h(...)
Le fait que ca marche sous gcc et pas VC++ est de la pure chance, car la spec ne dit pas quoi faire.
[^] # Besoin de vitesse de compilation (au moins pendant les cycles de dev)
Posté par herodiade . Évalué à 10.
Ils n'ont pas les moyens financiers de Linux (nombreuses sociétés et particuliers impliqués dans le dev/testing kernel et la libc + distros pour réparer en aval), pour s'offrir de gros clusters de Vax, Zaurus, hppa et de mac68k (et payer la note d'éléctricité !) à chaque fois qu'un header d'X.org ou de la libc change.
On peut donc aisément comprendre leur besoins de compilations rapides.
D'autre part, et au moins pour le moment, il ne s'agit pas de *remplacer* gcc par pcc (ni même de produire les binaires finaux de certaines archs avec pcc). Je crois que pour le moment l'intéret immédiat est simplement de disposer d'un compilo très rapide, pour accélérer le développement et la remontée de bugs, mais gcc reste là. D'après les explications que j'ai pu lire, c'est la motivation déterminante (et non une guerre de religion sur la licence).
(ps: accessoirement, recompiler tout le système avec un nouveau compilateur permet aussi de trouver de nouveaux bugs dans le système : Anders Magnusson dit avoir trouvé plein de bugs en compilant le userland NetBSD avec pcc).
[^] # Re: Besoin de vitesse de compilation (au moins pendant les cycles de dev
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
> aussi de trouver de nouveaux bugs dans le système
Parfaitement d'accord la dessus. Je me souviens avoir trouvé plein de bogue dans un programme qui marchait pourtant particulièrement bien lors du passage à Linux alors que le code compilait à l'époque sur SGI et SUN. Le jour ou on a eu un accès à un CRAY, on a encore retrouvé des bogues incroyable !
Bref, parfois, on se demande comment cela peut marcher aussi bien.
# Pourquoi changer ?
Posté par Victor . Évalué à 10.
# Re ; Fin de gcc dans les *BSD ?
Posté par zul (site web personnel) . Évalué à 8.
Pcc permet de compiler les sources de NetBSD/i386. Cela permet surtout de vérifier que le code est portable , et de détecter un certain nombre de gnuisme. Pour l'instant l'impact de pcc s'arrête la pour NetBSD.
Apres espie@OpenBSD.org a très bien expliqué les nombreuses raisons pour lesquelles ils seraient souhaitable d'avoir un autre compilateur de gcc. Rappellons par exemple qu'on a jamais reussi a booter un kernel VaX avec gcc3 ...
C'est à mon avis bien trop tôt pour intégrer pcc au cvs d'OpenBSD mais rien ne m'etonnent de leur part (ils feraient mieux de contribuer directement à pcc m'enfin je suis sur qu'ils vont préférer écrire OpenCC dans leur coin).
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par Psychofox (Mastodon) . Évalué à 6.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par zul (site web personnel) . Évalué à 2.
Toutefois, je suis convaincu de l'ininteret de rentrer pcc dans le cvs de OpenBSD.
Tout d'abord, parce que ca ne sert à rien pour 99,99 % des utilisateurs d'OpenBSD.
Deuxièment, parce que ce ne va pas accélérer le developpement de pcc en tant que projet externe. Ils vont devoir synchroniser regulièrement leur arbre de source avec celui de pcc (actuellement ils le font à la main ...) et ensuite ils vont faire une modification dans leur arbre puis au mieux remonter dans pcc la modification (et ils verront un bon conflit apparaitre lorsqu'ils synchroniseront les arbres de source).
Je ne vois donc pas l'interet d'avoir intégrer pcc à l'arbre de source, sauf evidemment si ils comptent "forker". M'enfin nous verrons bien.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par lasher . Évalué à 1.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par herodiade . Évalué à 5.
> de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop
> de trucs plus urgents à faire) à consacrer à un compilateur quelconque.
Pas beaucoup - pas assez - mais un petit peu quand même (de la main d'oeuvre). Par ex. :
- Un ou deux employés de Coverity (boite qui maintient un fork de gcc dédié à l'analyse statique de code) sont des développeurs d'OpenBSD (au moins Ted Unangst)
- Marc Espie, qui maintient depuis longtemps les semi forks de gcc (2.95 et 3.3.5 + patchs propolice) dans le système de base et dans les ports (4.0, 4.1, 4.2), et qui a les droits en écriture/commit dans le vrai depot svn de gcc
- Un certain nombre de développeurs ont cultivé des compétences liées, en ré-écrivant récemment le lint d'OpenBSD pour en faire un outil puissant et moderne (à la place de l'ancien lint, peu utilisable car floodeur de false positives)
- Maintenance, depuis longtemps,d'une paire de versions de gcc très adaptées à leurs besoins
- Et un paquet de spécialistes sur les « architectures minoritaires » (hppa, arm, mvme88k, ppc, sparc, ...).
Ce n'est certainement pas assez pour développer seuls un nouveau compilateur C complet, mais tout de même bien utile pour collaborer, avec d'autres, sur un compilateur déjà existant et bien architecturé. Au final ça ne fera sûrement pas un compilateur aussi complet (nombres de langages supportés) ou optimisé que gcc, mais fera probablement un bel outil complémentaire de gcc, pratique pour ceux qui ont les mêmes besoins qu'eux. Pas de raisons de s'en plaindre : ça n'enlève rien à personne, et ça profitera à certains.
Pour faire un peu d'informatique prédictive/fumeuse/astrologique ;), mon paris, c'est que ça donnera d'ici quelque temps un petit compilateur :
- C only (car ils n'ont pas besoins de C++ ou autre dans le système de base (sauf pour grof, mais il sera sûrement remplacé...))
- très rapide (car c'est un problème immédiat de gcc dont ils souffrent depuis longtemps, et qui leur coûte du temps)
- ayant une relative compatibilité avec les extensions gcc (ils en utilisent, et en auront besoin pour les ports)
- intégrant des fonctionnalités utiles pour la sécurité (puisqu'ils maintiennent déjà de nombreuses extensions de ce type dans leur fork "in house" de gcc)
- supportant un nombre décent d'architectures (puisque c'est capital pour eux et pour NetBSD)
- produisant du code peu optimisé (parce que ça demande beaucoup de travail et n'est pas une priorité immédiate pour eux, en tout cas moins importante que la rapidité de compilation)
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par IsNotGood . Évalué à 2.
Je vais faire une remarque naïve pour les z'élites d'OpenBSD, mais il me semble plus facile de corriger un bug de gcc que d'écrire un compilateur...
Je me trompe ?
Si à chaque bug/limitation de gcc il faut un compilateur, on n'est pas sorti de la merde...
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par Psychofox (Mastodon) . Évalué à 8.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par IsNotGood . Évalué à -7.
Vu comme ils prennent de haut gcc, ils ont intérêt à faire un truc qui arrache sa mère.
Je te paris que pcc restera un petit truc. Même les Gentoo lovers qui sont accros à la compilation ne vont pas l'utiliser...
J'en prend le pari.
Et si pcc c'est seulement faire un compilateur qui n'est pas cross-plateform, qui est peu optimisé, qui supporte peu de cpu, qui ne fait C et pas C++, etc, et bien il est mal venu de cracher sur gcc. Surtout qu'openBSD va rester dépendant de gcc pour encore très longtemps.
Mais ça c'est classique de openBSD boys. Ça ne manque pas une ocasion de cracher sur les outils GPL alors qu'ils les utilisent. Ce que j'utilise sous licence BSD, je ne crache pas dessus.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par Psychofox (Mastodon) . Évalué à 9.
Ce n'est pas parce qu'un projet est actuellement dépendant de gcc qu'il n'a pas le droit de critiquer certaines lacunes ou choix. Maintenant, si tu prends toute remarque négative comme une insulte envers ce projet, on ne peut plus rien dire dans ce cas la et rien n'avancera.
[^] # OpenBSD utilise gcc 3.3. Les nazes.
Posté par IsNotGood . Évalué à -3.
Dans le cas que tu donnes, oui.
Tu peux faire une critique de gcc, il y a toujours des choses à améliorer.
Mais dire que gcc est tellement pourrave qu'il faut passer à un "sous-compilateur", c'est une insulte.
Et quel est l'argumentaire pour "descendre" gcc ?
> GCC is developed by people who have vastly different goals from us.
Un compilateur, c'est un compilateur. Ce n'est pas une machine à café. Donc le "vastly different goals from us", je ne le comprend pas.
> Here is some *more* flame material.
C'est un compliment pour toi ?
> GCC is mostly a commercial compiler, these days.
Et ? Il l'a acheté combien ?
Il y a peu Theo se félicitait d'avoir des contributions de société et il trouvait ça bien. Mais si c'est GCC, "bing", ça devient mal.
Marrant.
Et pourquoi le "these days". Si ma mémoire ne me trahie pas, OpenBSD n'est même pas à la version 4 de gcc qui est sortie depuis des années. OpenBSD est à la version 3.3 (tout une époque...).
> They mostly target *fast* i386 architectures and PowerPC.
Et ?
C'est là où il y a le plus d'utilisateur, c'est là où il y a le plus de contribution.
Qu'il fasse pcc ou n'importe quoi, ça sera la même chose (pour peu que pcc soit vaguement populaire).
En passant, OpenBSD utilisant gcc 3.3, il ne doivent rien remarquer de ces modifications.
> *but* the compiler is getting bigger and bigger, and slower and slower (very much so).
Comment il le sait, OpenBSD est à la version 3.3 de gcc...
C'est con, mais gcc a gagné en rapidité ces derniers temps. Il en a perdu à l'introduction de SSA et maintenant il en gagne. De plus, ça ne veut rien dire. Un compilateur ce n'est pas un truc pour l'utilisateur final, ce n'est pas un jeux ou les fps compte, ça n'a pas des critères d'ergonomies, etc... Avant tout, il rend un service (compiler, générer du code machine). Le service est-il bon ? La majorité pense que oui.
> GCC warnings are not *really* useful. The -Wall flag shows many right things, and quite a few wrong issues.
Ben qu'il nous casse pas les couilles avec ça et qu'il désactive les warnings s'il veut coder comme porc. C'est ses oignons. NB : c'est l'option "-w" pour désactiver les warnings. C'est aussi configurable au niveau système.
> - There is a lot of churn in GCC which ends up with it no longer supporting some architectures that are still relevant to us.
Et ?
C'est ses oignons. Si personne ne veut d'une architecture mais seulement lui, ben qu'il retrousse ses manches. Passer à pcc ne change rien à ce problème.
pcc supporte des architectures "exotiques" ? Je ne crois pas.
Pcc est-il cross-plateform ? C'est important pour tester les architecture exotique sans avoir des tonnes de matériel.
> - The whole design of GCC is perverted
Encore un compliment ou une affirmation gratuite ?
> This is broken by design
Encore un compliment ? Une critique argumenté ?
> as the GPL people
La conspiration des adorateurs de la GPL. Mais oui...
> This also makes it impossible to write interesting tools, such as intermediate analyzers
C'est carrément impossible !
> This also makes it impossible to plug old legacy back-ends for old architectures into newer compilers.
?!?!
Si tu veux un vieux compilateur, utilise un vieux compilateur ! C'est exactement ce que fait OpenBSD. Il utilise gcc 2.95 et 3.3. Des vieux compilateurs.
Sûr que pcc n'aura jamais cette "feature" (utiliser des vieux backend avec un nouveau frontend). On en fait le pari ?
> every GCC update is an engineering nightmare,
Comment il sait ça?
OpenBsd n'est même pas à la version 4 de gcc...
> because there is NO simple choice. You gain some capabilities, and you also lose some important stuff.
S'il le dit...
En tout cas pour OpenBSD on n'en sait rien car OpenBSD a arrêté le temps depuis gcc 3.3.
> Even when you conform, it's hard to write code to the GNU coding standards, which are probably the most illegible coding guidelines for C. It's so obvious it was written by a lisp programmer. As a result, I've even lost interest into rewriting and getting in the GCC repository a few pieces.
La belle excuse....
> - some of their most recent advances do not have a chance to work on OpenBSD, like preparsed includes,
Ben il faut faire le portage. C'est un "peu" le boulot d'OpenBSD.
> which depend on mmap() at a fixed location.
Ben dans ce cas ça ne marche pas sous Linux non plus.
Le "méchant" Red Hat (et pas seulement Red Hat) utilise des adresses alléatoires pour RHEL et Fedora.
Bref, du gros pipo.
> - there are quite a few places in GCC and G++ where you cannot have full functionality without having a glibc-equivalent around.
C'est un problème de portage, c'est à OpenBSD de faire le boulot (du moins de ne pas se plaindre si ce n'est pas fait).
> - some of the optimisation choices are downright dangerous
Puisque tu le dis. Depuis quelques jours c'est un feux d'artifice d'exposion de bécane qui compile avec gcc.
> and wrong for us (like optimizing memory fills away, even if they deal with crypto keys).
C'est un problème de portage.
> - don't forget the total nightmare of autoconf/libtool/automake.
Toujours le même troll...
Ben qu'OpenBSD fasse l'équivalent d'autoconf/libtool/automake et qui marche partout. Après on en recause.
> And GCC is *the only program in the ports tree* that actually uses its own libtool. Its configuration and reconfiguration fails abysmally when you try to use a system-wide libtool.
Enfin une bonne critique....
Ce bug ne demande qu'à être corrigé.
Mais je m'interroge. Ça ne serait pas un bug de gcc 3.3 qui a été corrigé depuis des lustres ? Mais OpenBSD ne serait pas au courrant car il reste sckotché à gcc 3.3.
> I could actually go on for pages...
Compliment ou critique constructive ?
Et de quoi ?
De gcc 3.3 ?
> I will happily switch to another compiler, so frustrating has been the road with GCC.
Bon débarras. Qu'OpenBSD n'utilise plus GCC.
> I've actually been de facto maintainer of GCC on OpenBSD for a few years by now
Ça n'a pas été trop dure puisque que gcc est en version 3.3 dans OpenBSD.
Il y a peut-être encore gcc 2.95 dans la dernière OpenBSD que ça ne m'étonnerait pas.
Si tu veux des critiques constructives sur gcc, t'en trouvera ici par exemple :
http://www.gccsummit.org/2007/
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Psychofox (Mastodon) . Évalué à 3.
Tu ne t'es pas posé la question du pourquoi justement gcc est en 3.3 dans openbsd ?
Je te laisse te masturber sur la superiorité de redhat qui se bat sans relâche contre le monde entier qui ne désire que sa perte.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par IsNotGood . Évalué à 0.
Peut-être car openbsd n'a quasiment rien fait depuis au moins 3 ans dans gcc ?
Ce n'est pas peut-être, c'est sûrement.
> Je te laisse te masturber sur la superiorité de redhat qui se bat sans relâche contre le monde entier qui ne désire que sa perte.
Quand as-tu lu ou entendu que j'avais peur pour l'avenir de Red Hat ?
Jamais.
Toi tu retournes te masturber sur ce que j'aurais dit sur Red Hat et sur les trolls d'OpenBSD sur gcc.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par briaeros007 . Évalué à -3.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Psychofox (Mastodon) . Évalué à 6.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par briaeros007 . Évalué à -3.
Le-dit pourquoi étant très bien expliqué dans la citation de espie@.
Marrant que tu estime que c'est très bien expliqué alors que quelqu'un estime le contraire.
Quand il t'en fait la remarque , avec un poste reprenant POINT PAR POINT les remarques, tout ce que tu trouve a dire c'est 'mais non cette citation est super top génial. C'est toi qui a pas d'argumentation. Je démontre pas en quoi elle est cool malgré le fait que tu l'a repris point par point. Elle est bien et c'est toi qui fait des remarques évasives et ne se pose aucune question comme pourquoi ni comment.'
De mon point de vue ca fait pas très sérieux ce genre de comportement (je ne tomberais pas dans la bassesse des attaques ad hominem, que certains dans ce threads affectionne).
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Bapt (site web personnel) . Évalué à 7.
OpenBSD dispose toutes les versions *récente* de GCC au travers des ports : http://ports.openbsd.nu/lang/gcc jette un oeil et tu verras, il y a même des ports pour les version 4.X et même celle en dev (4.3), donc tu as bien des mecs qui se prennent la tête a intégrer gcc dans OpenBSD y compris dans les versions récentes. En plus c'est la même personne qui les maintient, mais comme tu le dis, le mec ne doit pas savoir il en son resté à la version 3.3...
De plus si OpenBSD en est resté à la version 3.3 pour la compilation des sources officielles, et 2.95 pour certaines archi, c'est peut être bien parce que gcc n'est peut être pas si facile que ça a intégrés : comme dit dans ce que tu quotes : certaines architectures non supportés, du GNUisme, des buts différents de ceux des devs d'OpenBSD. Bah dans ces cas là tu changes dès que tu le peux pour un produit qui leur correspond mieux.
Ensuite pour les postes de baves sur GCC, si tu lis les premiers posts (je ne parles de trollfr, mais bel et bien des annonces officielles) qui parlent de l'import de pcc dans gcc ça ne bave pas sur GCC, mais ça dit juste que PCC pourrait mieux correspondre à leur besoin, par la suite ça bave car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi, et comme des gens prêt à troller et à baver il y en a *plein* dans tous les camps, (Théo est très souvent en première ligne pour ça, mais Linus n'est jamais bien loin non plus.) ça crache dans tous les sens.
Toi par exemple dès ton premier post du bave sérieusement sur les BSD : http://linuxfr.org/~inico/25304.html#867189
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par IsNotGood . Évalué à 2.
J'en ai rien à foutre qu'OpenBSD utilise autre chose que gcc. Vu comme OpenBSD est prêt systématiquement à gerber sur Linux et la GPL, j'en serai heureux même. Il donne systématique des leçons, critiques les outils GNU, etc...
Très bien, qu'ils ne les utilisent pas. S'ils ne les utilisent pas et font du troll/fud, ça m'énerverait beaucoup moins.
Ce qui m'insupporte c'est de voir des gens qui profitent de gcc et vomissent sur gcc.
De combien à contribué OpenBSD à gcc ?
0,01 % ou 0, 02 % ?
Pourtant OpenBSD utilise 100 % de gcc.
On va dire encore qu'il n'ont pas les moyens de développer un compilateur. Très bien encore. Avec gcc, ils ont quelques qu'il n'ont pas les moyens de développer. Ça fait encore une raison de moins de critiquer gratuitement gcc.
> du GNUisme
C'est une seconde nature...
Vois ta contradiction :
- "car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi,"
Si je suis "GNUiste" alors je ne ferai pas une levée de bouclier.
Alors, je suis "GNUiste" ou non ?
C'est de la critique gratuite/facile tout ça. Si gcc est comme ci alors c'est mal et s'il est comme ça alors ... c'est mal aussi. Tout ce qui n'est pas gcc est bien. Dans ce cas, il faut assumer et ne pas utiliser gcc.
J'utilise openssh, je ne vomis pas sur openssh. Pourtant il y a une alternative GPL.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Psychofox (Mastodon) . Évalué à 4.
euh...qu'est-ce que tu fais dans ce journal alors ?
C'est qui OpenBSD ? personne. Si tu parle de Théo de Raadt, ben il ne s'est même pas exprimé publiquement au sujet de pcc. La seule chose que Theo et Miod ont fait, c'est accepter l'inclusion de pcc dans le cvs de openbsd pour pouvoir bosser dessus.
Maintenant faut pas mélanger les propos personnels d'un leader de projet, les choix techniques de plusieurs autres et les avis de ses utilisateurs...
Du reste personne n'a vomi sur gcc. Le titre de undeadly, c'est "BSD Licensed PCC Compiler Imported" et le log de l'ajout dans le cvs est "Import ragge's version of PCC into our tree, so we can hack on it more easy. ok deraadt@ miod@" et pour netbsd c'est "Initial import of ragge's version of pcc, version 0.9.8. This is the latest version of the portable C compiler" suivi d'une description et un historique de pcc. Rien dans tout cela n'attaque le projet gcc.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par briaeros007 . Évalué à -1.
Ben si tu apprenais a lire plutot qu'a attaquer, tu remarquera qu'il dit ce qu'il pense : a savoir 'que critiquer un outil quand on l'utilise, surtout avec des critiques fausses et non argumenté m'insupporte'.
Et je tend a etre plutot de son avis.
Mais comme on est des GPLeux on pas le droit de parler , c'est ca?
Si tu parle de Théo de Raadt, ben il ne s'est même pas exprimé publiquement au sujet de pcc.
Et tu quote un truc qui ne parle pas de pcc, ca tombe bien.
Du reste personne n'a vomi sur gcc
Non dire que c'est 'defective by design' ou alors que le "design is perverted", c'est des compliments hein
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Psychofox (Mastodon) . Évalué à 3.
Raisonnement tordu. C'est quand on utilise un outil qu'on est capable d'y formuler les critiques les plus pertinentes.
'fin sauf si tu considère que quelqu'un a plus de légitimité à critiquer le Guitarangi da Gamba s'il ne sais pas jouer de la musique...
note qu'il y'a un "si" dans ma phrase, parce que l'idiot n'est pas capable de se rendre compte qu'OpenBSD n'est pas un être humain mais un OS. Et je contredis un post lançant des accusations vagues et sans sources, c'est donc difficile d'être plus précis...
euh...as tu une idée de la notion de contraste et de nuance. Entre ne pas être d'accord avec un choix de design (comme l'est Marc Espie) et "vomir" dessus, il y'a une nuance. Si espie@ "vomissait" sur gcc, il ne se serait jamais cassé le cul à y contribuer...
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par briaeros007 . Évalué à 1.
Ca confirme donc ce que je disais :
(passage en gras ce sur quoi tu confirme mes dires)
Entre ne pas être d'accord avec un choix de design (comme l'est Marc Espie) et "vomir" dessus, il y'a une nuance. Si espie@ "vomissait" sur gcc, il ne se serait jamais cassé le cul à y contribuer...
Ca dépend quel nuance tu accorde à 'vomir'.
Dire 'c'est pourri jusqu'a la moelle' (traduction de defective by design : on pourra jamais en faire qqch de bien sans tout recasser), ben désolé pour moi c'est pas une 'petite critique sans importance'.
Enfin des fois tu contribue a un truc 'tres moche' pour le rendre 'un peu moins moche'.
Maintenant si tu fait/vend/... un logiciel et que quelqu'un en dis qu'il est pourri jusqu'a la moelle. Tu considérera qu'il en fait une critique argumenté, tout juste ce qu'il faut pour faire avancer dans le bon sens, ou plutot qu'il vomi sur ce soft ?
Moi j'ai tendance a penser la seconde version, et je pense que je ne suis pas le seul.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Psychofox (Mastodon) . Évalué à 4.
ça ne confirme rien, c'est hors sujet...
Sauf que citer "defective by design" comme fait plus haut sans lui ajouté l'explication qui suit, c'est juste passer un post à la machette pour lui faire dire ce qu'on veut.
D'ailleurs pourri jusqu'à la moelle n'est pas du tout une bonne traduction de defective by design. pourri implique une décomposition, dégradation. defective by design au contraire implique que le choix du design est mauvais à la base. Bref comme tu sais très bien pervertir les phrases des autres pour y donner le sens que tu veux, c'est pas vraiment la peine que je continue la discussion.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par briaeros007 . Évalué à 2.
Quel argumentation.
Plutot qu'argumenté ce en quoi les arguments en question sont ou non pertinent.
Plutot que d'explicité où tu montre justement qu'ils sont pertinent, tout ce que tu dis c'est
'Non , j'ai décidé que c'était HS' , alors que je reprend juste deux de nos réponses. Donc soit c'était HS avant, et dans ce cas tu aurais du le dire, soit c'est pas HS et dans ce cas ce n'est TOUJOURS pas HS.
Ah j'oubliais (vu les notes), sur ce thread faut pas oser contredire un bsdiens, apres tout je suis qu'un gpleux, n'est ce pas ?
Sauf que citer "defective by design" comme fait plus haut sans lui ajouté l'explication qui suit, c'est juste passer un post à la machette pour lui faire dire ce qu'on veut.
Et pourquoi tu n'as pas citer cet argument plutot que dire 'muwahhh vous dites que des conneries, d'abord c'est meme pas vrai' ?
D'ailleurs pourri jusqu'à la moelle n'est pas du tout une bonne traduction de defective by design. pourri implique une décomposition, dégradation. defective by design au contraire implique que le choix du design est mauvais à la base.
Je t'embaucherais pas comme traducteur.
Quand on dis que quelqu'un est pourri jusqu'a la moelle, ca veut dire quoi ? Qu'il se dégrade de l'intérieur ?
Avant de partir sur du littéral, il faut d'abord voir le sens de l'expression (qui n'est PAS se dégrader de l'intérieur, mais bien qu'on ne peux rien en tirer, bon à jeter.)
Puis comme cette expression est une 'mauvaise traduction', quel expression nous proposes tu alors ?
Bref comme tu sais très bien pervertir les phrases des autres pour y donner le sens que tu veux, c'est pas vraiment la peine que je continue la discussion.
Perverir les phrases ? Ou ca ?
Oser une traduction, qui peut etre polémique mais que je peux argumenter ?
Oser argumenter mes posts ? (je crois que la longueur de nos posts respectifs le montre un peu, qui même si elle n'est pas en corrélation directe avec l'argumentation, elle y contribue : un post de trois ligne sera rarement bien argumenté)
C'est ca pervertir les phrases des autres.
Ps tu m'a fait une reflexion sur 'tu sais pas traduire'. Je te conseillerais donc de te renseigner sur le sens du verbe 'pervertir'.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Miod in the middle . Évalué à 10.
***
Tout d'abord, rappelons que gcc a été l'un des premiers compilateurs C sous licence libre. Et quand je dis "l'un des premiers", soyons sérieux un instant, il n'existait que _deux_ compilateurs libres : pcc, qui était quasiment abandonné sans que personne ne reprenne le navire, et gcc.
Les autres compilateurs étaient non libres (comme lcc) ou n'ont pas réussi à se faire connaître aussi bien que gcc (souvent parce que leur cible n'étaient pas les systèmes de type Unix).
Gcc 1 a donc eu un boulevard pour se développer, et a tout naturellement capté les meilleures compétences. Le vide s'est fait petit à petit, avec les compilateurs propriétaires (mipspro, Sunpro, XLC, etc) d'un côté et gcc de l'autre.
À cette époque, on est encore à la fin des années 1980, les systèmes libres ne pèsent rien du tout.
Un certain Michael Tiemann adapte gcc pour le support du C++ lors de sa thèse à l'INRIA, ce qui provoque l'éclatement de gcc 1 en une conception plus modulaire permettant de gérer plusieurs languages : gcc 2 est né. Tiemann fonde Cygnus dans la foulée.
Vous suivez toujours ? Gcc 2 sort au début de l'année 1992. À cette époque, on commence seulement à avoir des compilateurs C++ solides, qui ne sont plus des compilateurs C avec une surcouche comme l'était CFront, et qui peuvent enfin gérer les constructions les plus complexes que permet le language.
Afin d'aider à asseoir la notoriété et l'utilisation de gcc (et surtout de g++), Richard Stallman impose que les deux parties de gcc (celle qui traduit un des langages supportés en la représentation interne RTL, et celle qui traduit le RTL en du code assembleur) ne puissent pas être disjointes, de façon à ce qu'un vendeur de compilateur propriétaire ne puisse pas utiliser par exemple l'analyseur syntaxique C++ de gcc 2, et mettre son propre générateur de code assembleur derrière.
C'est un choix qui va à l'encontre de la philosophie Unix (qui favoriserait ``gcc-highlevel monfichier.c | gcc-lowlevel | as -o monfichier'' avec un gcc en deux composants distincts), mais qui est compréhensible dans l'optique "pénaliser le code propriétaire à tout prix" du projet GNU.
Par contre, d'un point de vue d'ingénieur, c'est une décision regrettable, ne serait-ce que pour déboguer : tu peux demander à gcc de te "cracher" 30 fichiers de représentation intermédiaire correspondant à 30 étapes d'optimisation, mais tu n'as aucun moyen, lorsque tu crois avoir détecté une erreur à la passe N, de modifier manuellement ce fichier et de le réinjecter à la passe N+1, afin de vérifier ton hypothèse dans le code final.
C'est sur ce point que râle perpétuellement Marc Espie (la partie "perverted design").
***
Un autre reproche, peut-être plus spécifique à OpenBSD, est le choix des plate-formes supportées par gcc. Gcc évolue de plus en plus vite, c'est bien (et ça change du cycle de release entre 2.5.8 et 2.8...), mais du coup il est difficile de suivre quand tu as d'autres choses à faire à côté. Les développeurs de gcc ne testent pas tous toutes les plate-formes pour lesquelles gcc est capable de produire du code (que ce soit en natif ou en compilation croisée), et le résultat est que sur les N plate-formes supportées par gcc, seule une bonne moitié est vraiment fiable, les autres souffrant de bugs par ci par là, qui peuvent très bien être indétectés avant belle lurette, ou produire des erreurs subtiles dans le comportement d'un programme difficile à analyser.
Il y a plusieurs plate-formes où, par manque d'intérêt ou de gens payés pour, le "backend" de gcc est fiable en version N, mais plus en version N+1, soit à cause de bugs bêtes, soit parce que les optimisations plus fines de cette nouvelle version de gcc cassent certaines choses "considérées comme acquises" (comment traduire ``assumptions'' ?) par le code du backend. Pire encore, le backend peut être mal écrit initialement et mal décrire la réalité du processeur.
Dans ce cas, il y a un travail important à accomplir, et de nos jours, à la vitesse où sont introduits dans gcc des changements (nouvelle représentation intermédiaire, nouvelles optimisations, nouveau modèle de gestion du parallélisme) nécessitant des modifications substancielles du backend, il n'est pas possible de suivre si l'on ne dispose pas de beaucoup de temps à consacrer à gcc.
On le voit très bien dans les changelog de gcc ou les backend sont de facto en deux classes : ceux qui sont maintenus, souvent par des personnes payées à plein temps pour le faire par IBM, Apple, Sony ou autres, et ceux pour lesquels les seuls changement visibles sont des changement systématiques (remplacement de VIEIILLE_MACRO() par NOUVELLE_MACRO(), correction de fautes d'orthographe dans les commentaires, extension du copyright à la nouvelle année tous les ans) dont il a simplement été vérifié de temps en temps qu'ils compilent, et aucune autre activité.
C'est une source de mécontentement croissante, parce que justement cela montre que gcc (et plus particulièrement gcc 4) peut de moins en moins être présenté comme supportant autant de plate-formes que par le passé.
***
Le troisième reproche fait à gcc est la lenteur croissante des temps de compilation.
Autant les migrations successives de 2.1 à 2.95 ont conservé des temps de compilation proches, autant chaque version intermédiaire de gcc 3 a impacté les temps de compilation de façon significative (30 à 70% selon les plate-formes, pour un passage de 2.95 à 3.3, les plate-formes le plus affectées étant celles disposant de beaucoup de registres : alpha, hppa, mips, sparc).
Heureusement, 4.1 puis 4.2 commencent à bien digérer le passage à la représentation ssa, et regagnent du temps sur 3.4 (on constate généralement des temps intermédiaires entre ceux de 3.3 et ceux de 3.4, lorsque l'on compile avec 4.2).
Mais, comme je le disais un peu plus haut, il arrive que le support d'une architecture donnée soit absent ou non fiable en 4.x. Voire en 3.x. Donc, faute de moyens (essentiellement en temps), on en reste à gcc 2.95.
Le fait que les développeurs de gcc ne soient pas intéressés pour aider à migrer un backend 2.95 au niveau 3.4 ou 4.x, n'aide pas non plus à la motivation.
***
On en vient alors à "mais s'ils sont aussi mécontents de gcc, qu'ils utilisent donc autre chose !".
Oui, on aimerait bien. D'ailleurs on y pense depuis longtemps, et plusieurs développeurs OpenBSD s'étaient intéressés à TenDRA il y a moult années déjà.
Mais comme je l'ai rappelé plus haut, gcc a fait le vide autour de lui. TenDRA, par exemple, n'était plus maintenu depuis la fin des années 1990, et le groupe qui s'est monté pour le reprendre a surtout réussi à se tirer dans les pattes et à se scinder en deux groupes encore moins actifs.
Ce qui fait la différence dans pcc, c'est qu'il est plus facile de "rentrer" dans le code que dans celui de TenDRA, et que les projets BSD ont de très bonnes relations avec Ragge (Anders Magnusson) à l'origine du renouveau de pcc.
La situation est donc différente : ce n'est plus reprendre un projet dont l'équipe a mis la clef sous la porte, mais c'est s'injecter dans un projet bouillonnant, et qui n'intéresse d'ailleurs pas qu'OpenBSD : sur la liste de développement de pcc, on trouve aussi des gens de DragonflyBSD et NetBSD.
***
Je terminerai en rappelant qu'il est évident qu'il reste beaucoup de travail à accomplir. Pcc n'est pas près de remplacer gcc dans OpenBSD, mais on va essayer de le faire mûrir pendant quelques mois, afin de voir quel effort est réellement nécessaire pour obtenir une alternative viable à gcc.
Ceux qui s'imaginent que c'est pour demain sont de doux rêveurs... tout comme ceux qui s'imaginent que c'est une tâche impossible.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par IsNotGood . Évalué à 1.
Ce n'est pas pénaliser, c'est ne pas voir son code "perverti" en un truc proprio.
Si gcc pouvait avoir des greffon proprio, il y a des risques.
Linux a aussi le même problème (avec les modules).
GCC peut produire des binaires proprio car ça ne change pas le caractère libre de gcc. Comme Linux peut exécuter des logiciels proprio car ça ne change rien au caractère libre de Linux. Bien que gcc peut produire du code proprio, gcc reste totalement libre. gcc n'est pas un moyen pour empêche le développement de proprio (ou des trucs sous BSD).
> C'est une source de mécontentement croissante, parce que justement cela montre que gcc (et plus particulièrement gcc 4) peut de moins en moins être présenté comme supportant autant de plate-formes que par le passé.
Et ce qui arrivera, c'est mon avis, c'est que gcc ne supporte officiellement qu'un petit nombre d'architecture. Pour les architectures particulières, ça sera des forks.
Le problème de nombre d'architecture supporté se retrouves partout et n'a rien de spécifique à gcc. Linux (le noyau) a le même problème. Bien des choses ne marchent pas quand tu sors des architectures "classiques".
Mais que faire ? Demander aux développeurs de bosser spécifiquement pour 1 % des utilisateurs au détriment de 99 % des utilisateurs ?
Je suis contre.
Demander aux développeurs de bosser spécifiquement pour 1 % des utilisateurs au détriment de 99 % des utilisateurs ?
C'est du logiciel libre, ils bossent sur ce qu'ils veulent. S'ils ne veulent pas bosser sur l'architecture bidule, il faut faire avec.
> Mais comme je l'ai rappelé plus haut, gcc a fait le vide autour de lui.
Gcc n'est pas un aspirateur. Il y avait déjà le vide.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par zul (site web personnel) . Évalué à 6.
Des risques de ? Qu'une société écrive un backend propriétaire ? Et donc ? Cela réduirait la liberté de qui ? Personne ne t'interdirait d'écrire un backend libre, personne même ne t'oblige à utiliser ce backend proprio. Tout comme perso t'oblige à utiliser un module propriétaire sous Linux. La liberté est avant tout un choix ...
> C'est du logiciel libre, ils bossent sur ce qu'ils veulent. S'ils ne veulent pas bosser sur l'architecture bidule, il faut faire avec.
gcc est un logiciel libre certes, mais reveille toi. La majorité des contributeurs de gcc et de linux sont des grosses boîtes qui voient leurs intérets avant tout.
Respecte alors le choix de ceux qui critiquent gcc (en connaissant bien mieux gcc que toi à priori) et qui veulent une alternative plus en adequation avec leurs attentes.
Au passage, merci Miod pour ce petit historique.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par briaeros007 . Évalué à 1.
Meme question avec des firmwares proprio dans le noyau.
Le plus drole c'est que quand la bsd est utilisé par des entreprises, meme pas pour faire du proprio, une partie de ses défenseurs (comme théo par exemple) vient raler parce qu'il ne recoit pas de thune.
Ne pas voir son code repris dans un logiciel proprio est une volontée que je comprend très bien.
gcc est un logiciel libre certes, mais reveille toi. La majorité des contributeurs de gcc et de linux sont des grosses boîtes qui voient leurs intérets avant tout.
Et ?
C'est quoi ton point la ?
Que des boites contribuent au libre ?
Cool.
Que parce que c'est des boites faut refuser leurs patchs ?
Voit pas pourquoi.
Qu'un contributeur contribue suivant ce qui l'intéresse et pas ce qu'intéresse tartenpion ?
Franchement impressionnant la !
Bref le coup du 'réveille toi' me laisse perplexe.
Respecte alors le choix de ceux qui critiquent gcc (en connaissant bien mieux gcc que toi à priori)
En l'exprimant bien moins bien alors (ie commentaire d'espi).
Par contre tu vois le commentaire de miod a été plutot assez clair.
et a bien expliqué les différents points (enfin ce n'est que mon point de vue).
Est ce pour autant qu'on est forcé d'être d'accord avec les arguments engagé ? non.
IsNotGood a une position différente de la GPL de miod.
C'est donc qu'il a forcément tort ?
Ou sont donc les arguments ou contre argument ?
Miod en a, isnotgood en a.
Je vois donc pas de mal a ce qu'ils en discutent.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par satan . Évalué à 6.
Le pragmatisme de GCC a fait ses preuves. Apple ne serait pas en train de maintenir la partie Objective C de gcc à l'heure actuelle si GCC était sous une licence BSD-like. NeXT a essayé il y a bien longtemps de créer leur compilateur Objective C par dessus gcc tout en le faisant propriétaire. La FSF est allé leur dire deux mots et ils ont été obligé de libérer le code.
La GPL est bien plus pragmatique qu'idéologique, dans le monde réel. Elle a permis à des softs comme GCC de recevoir des contributions de la part de personnes qui n'avaient pas envie d'en donner, mais qui ont préféré utiliser un logiciel GPL comme GCC plutôt que de devoir recréer tout un compilateur from scratch, le cas de NeXT.
La BSD contrairement aux idées reçues n'est pas la licence idéale pour les entreprises qui font du proprio, si l'entreprise en question mets beaucoup d'argent derrière le logiciel en bsd. Faut voir Trolltech et MySQL par exemple, qui font du business à base de double licence GPL/proprio. Ca ferait pas bander Trolltech si tout le monde pouvait propriétariser QT. La GPL leur permets de faire du libre tout en ayant un business model avec les marchands propriétaires. La BSD est anti-business. Pour une entreprise qui produit du software, mettre un logiciel sous double licence est bien plus rentable que se de faire piller son code par tout le monde, puis ça va revenir cher la facture en vaseline..
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par zul (site web personnel) . Évalué à 3.
Cela reste bien evidemment à prouver. On peut se souvenir de khtml et apple. Certes, le code était sous GPL m'enfin on sait ce que ca a longtemps donné ... Il faut aussi voir que le seul utilisateur de Obj C c'est apple et sa communauté. Et même sous une licence BSD-like, je vois pas la plus value qu'ils auraient à garder le code propriétaire.
La question de plus n'est pas là (GPL vs BSD) pour gcc. Le problème vient du design qui a été bousillé pour éviter qu'un module propriétaire ne s'immisse dans la châine de compilation. Ce n'est pas une décision pragmatique, du point de vue ingéniérie....
Quand on commence à me parler de rentabilité financière sur linuxfr, je me dis que le monde va bien mal :) Moi qui était persuadé que le logiciel libre, c'était d'abord une question d'éthique et de partage. Je suis vraiment un gros con ... :D
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par satan . Évalué à 5.
On s'en fout que tu ne vois pas la plus value, moi non plus comme toi je ne vois pas la plus value mais on s'en fout de nos pensées parce que là on parle de *faits*. Les faits sont là : NeXT a essayé de faire du proprio avec l'Objective C, la FSF leur a donné un coup de bâton, fin de l'histoire. Je parle d'Apple parce qu'objectivement c'est le NeXT d'aujourd'hui, son Steve Jobs, son objective C, ses APIs cocoa et les mêmes ingénieurs de l'époque..
Consider GNU Objective C. NeXT initially wanted to make this front end proprietary; they proposed to release it as .o files, and let users link them with the rest of GCC, thinking this might be a way around the GPL's requirements. But our lawyer said that this would not evade the requirements, that it was not allowed. And so they made the Objective C front end free software.
C'est un évènement qui s'est déjà produit et dont la finalité est celle qu'elle est parce que la licence de GCC les a forcé à libérer le code.
Et non Apple n'est pas le seul utilisateur d'objective C, même s'ils sont la seule plateforme où on fait du fric avec, dans le monde du libre tu as GNUStep et le projet de bureau Etoilé qui font usage de ce langage.
Quant à KHTML, Apple avait déjà eu une expérience avec le libre et ils ont compris qu'ils étaient obligés de suivre les licences des logiciels qu'ils emploient, c'est pour ça que le code de KHTML modifié par Apple a été libéré. C'est du LGPL, donc ils ont libéré que ce qu'ils étaient obligés de libérer, ainsi qu'une portion de leur API de haut niveau (webkit) mais ils n'ont pas libéré Safari évidemment.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par herodiade . Évalué à 8.
> warnings s'il veut coder comme porc.
Visiblement, tu te méprend sur le sens de sa remarque.
À titre indicatif, le noyau d'OpenBSD est compilé, en boucle, sur toutes les archs, avec par défaut (en dur dans les Makefile) :
cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wstack-larger-than-2047
Et leur version de gcc dipose d'un certain nombre de warnings suppélementaires, en rapport avec leurs priorités (dont le -Wstack-larger-than-x plus haut, et -Wbounded (pour faire des verifs contre les débordements), -Wformat (pour faire des verifs contre les possibilites de format string vulnerabilities).
Bref on ne peut vraiment pas dire qu'ils soient contre l'idée générale des Warnings du compilo, mais plutôt qu'ils voudraient plus de warnings sur les choses ayant un impact sur la sécurité, et un meilleur rapport signal/bruit.
>> every GCC update is an engineering nightmare,
> Comment il sait ça?
> OpenBsd n'est même pas à la version 4 de gcc...
Mar Espie est un développeur de gcc depuis longtemps (il a accès en écriture au depot svn de gcc et a pas mal contribué...). Ce qui lui donne à la fois plus de crédibilité et de légitimité que toi, trolleur de linuxfr (as-tu contribué au projet gcc ?). Je pense qu'il sait mieux que toi ce qu'apporte (ou pas) la version 4 de gcc...
Et cela lui donne, peut-être aussi, le droit d'indiquer ses souhaits et deceptions au sujet de certaines orientations *politiques* du projet (par exemple à l'époque où il avait soutenu la proposition d'intégrer propolice dans gcc).
Accessoirement, son reproche central, le fait que, pour des raisons purement politiques (et en conflit avec l'interet technique) le frontend et le backend soient mélangés est un reproche fortement partagé par Linus Torvalds, et a motivé l'écriture et le choix de la licence de sparse.
FAQ de sparse, par Linus Torvalds :
Sparse étant, disons, un demi-compilateur, tu vois qu'il y a d'autres gens très respectable qui font la même chose que les devs OpenBSD, à savoir maintenir un outil, en parallèle à gcc, pour pallier aux mêmes limitations artificielles (car politiques) de gcc.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par zul (site web personnel) . Évalué à 2.
OpenBSD doit possèder gcc 2.95 pour la même raison pour laquelle NetBSD le gardait, à savoir le port VaX.
Le passage en version 4.x leur permettrait
1/ de pas avoir à avoir deux gcc dans leur base systeme
2/ les empecherait de faire du buzz (vu que SSP est de base dans gcc 4.x, OpenBSD n'apporterait plus beaucoup de plus value).
Le passage à gcc4 permet a aussi de corriger divers "bugs" dans NetBSD (d'incorrections en tout cas).
La série 4.x a quand même introduit un warning très chiant, celui qui dit que les variables peuvent être non initialisés, et 90% du temps il se plante. Comme les BSD utilisent -Werror, ca bloque la compilation pour un faux motif et ca oblige à faire une "fausse initialisation" pour calmer gcc.
Sinon, je suis relativement content de gcc4. J'attend l'intégration de gcc 4.2 dans NetBSD.
Ca n'empeche pas qu'il est intéressant de pouvoir compiler les sources avec un autre compilateur. C'est ca aussi la correction et la portabilité du code.
M'enfin, oui la majorité des OpenBSDistes sont des gros trolleurs :) Certains de leurs objectifs sont intéressants mais ils jouent souvent plus sur le buzz et le bruit que sur ce qu'ils font vraiment. (commentaire du vendredi en avance).
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par zul (site web personnel) . Évalué à 2.
Je te conseille d'ouvrir les sources de gcc. Tu comprendras tout de suite pourquoi il est difficile de corriger un bug, quand tu n'es pas un gourou gcc.
Tu as l'air très doué. Je pense que tu va pouvoir aider la communauté BSD... Yapluka
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par IsNotGood . Évalué à -2.
Ben pareil avec mes sources.
Tous truc "technique" est compliqué. On ne devient pas codeur gcc ou Linux du jour au lendemain.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par briaeros007 . Évalué à 2.
Ben non, c'est un sale gpleux qui pux. il se fera jeter des cailloux si il apporte du code.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par ciol . Évalué à -3.
gcc (et d'autres logiciels GNU), ont été commencés il y a longtemps.
D'où par exemple tous les #ifdef BSD, #if HAVE_STDIO_H, placés par soucis de compatibilité.
Il est toujours plus facile de refaire quelque chose proprement, en ayant connaissance des erreurs à ne pas faire et des nouvelles techniques, que d'améliorer l'existant.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par ribwund . Évalué à 3.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par Psychofox (Mastodon) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.