Lamentations du développeurGCC 2.96La toile de fond:
La série GCC 2.95 est une version GNU officielle et
la version 2.95.3 de GCC est la version la plus exempte de bogues de toute la série.
Nous n'avons jamais remarqué de problèmes de compilation que nous pourrions attribuer
à GCC 2.95.3. A partir de Red Hat Linux 7.0, Red Hat
a inclus une version CVS lourdement patchée de GCC dans sa distribution et l'a nommé
2.96. Red Hat a inclus cette version parce que GCC
3.0 n'était pas terminé à ce moment là, et ils avaient besoin d'un compilateur
fonctionnant sur toutes leurs plateformes supportées, incluant IA64 et s390. Le
distributeur Linux Mandrake a également suivi
l'exemple de Red Hat et a lancé la diffusion de GCC 2.96 avec sa série Linux-Mandrake 8.0.
Les évènements:
L'équipe GCC a nié tout lien avec GCC 2.96 et a publié une
réponse officielle
à GCC 2.96. De nombreux développeurs à travers le monde ont commencé à avoir des
problèmes avec GCC 2.96, et ont commencé à recommander d'autres compilateurs. Par Exemple
MySQL,
avifile
et
Wine.
D'autres liens intéressants sont
Linux kernel news flash about kernel 2.4.17
et le Forum Voy.
MPlayer a également souffert des problèmes intermittents qui
ont tous été résolus en passant à une version différente de GCC. Plusieurs projets en
commencé d'implémenter des contournements pour quelques-uns des problèmes de 2.96, mais
nous avons refusé de réparer les bogues des autres, surtout parce que certains
contournements peuvent impliquer une pénalité sur les performances.
Vous pouvez lire un autre point de vue sur cette histoire
sur ce site. GCC 2.96 n'autorise
pas les caractères | (pipe) dans les commentaires assembleur parce
qu'il supporte aussi bien la syntaxe Intel que la syntaxe AT&T et que le caractère
| est un symbole dans la variété Intel. Le problème est qu'il ignore
silencieusement le bloc assembleur entier. Cela est
théoriquement fixé maintenant, GCC affichant un warning au lieu de sauter le bloc.
Le présent:
Red Hat dit que GCC 2.96-85 et supérieur est réparé. La situation c'est en effet
améliorée, mais nous voyons toujours des problèmes sur les listes de diffusion qui
disparaissent avec un compilateur différent. Dans tous les cas cela ne peut plus durer.
Normalement un GCC 3.x mature résoudra les problèmes. Si vous voulez compiler avec 2.96
passez l'option à configure.
Rappelez-vous que vous êtes seul et donc de ne pas rapporter de bogues.
Si vous le faites, vous serez juste insulté voir banni de nos listes de diffusion car
nous en avons plus qu'assez des empoignes sur GCC 2.96. S'il vous plaît, restons-en là.
Si vous avez des problèmes avec GCC 2.96, vous pouvez obtenir les paquetages 2.96-85
sur le serveur ftp de Red Hat, ou
d'utiliser les paquetages 3.0.4 offerts avec la version 7.2 et supérieur. Vous pouvez
également obtenir les paquets gcc-3.2-10
(non officiels, mais fonctionnant bien) et vous pouvez les installer avec le GCC 2.96
que vous avez déjà. Mplayer les détectera et utilisera 3.2 au lieu de 2.96. Si vous ne
voulez pas ou ne pouvez pas utiliser les paquetages binaires, voici comment vous pouvez
compiler GCC 3 depuis les sources:
Allez sur la
page des miroirs GCC
et téléchargez gcc-core-XXX.tar.gz où
XXX est le numéro de version. Ceci inclue le compilateur C
complet et est suffisant pour MPlayer. Si vous voulez
aussi C++, Java ou certaines autres fonctions avancées de GCC,
gcc-XXX.tar.gz pourrait mieux convenir à vos besoins.
Décompressez l'archive avec
tar -xvzf gcc-core-XXX.tar.gz
GCC n'est pas construit depuis le répertoire source lui-même comme c'est le cas pour
la plupart des programmes, mais a besoin d'un répertoire de construction à l'extérieur
du répertoire source. Vous devez donc créer ce répertoire via
mkdir gcc-build
Ensuite vous pouvez procéder à la configuration de GCC dans le répertoire de
construction, mais vous aurez besoin de le configurer depuis le répertoire source:
cd gcc-build
../gcc-3.XXX/configure
Compilez GCC en tapant cette commande dans le répertoire de construction:
make bootstrap
Maintenant vous pouvez installer GCC (en root) en tapant
make installDistribution binaireMPlayer contenait précédemment du code source du projet
OpenDivX, qui interdit toute redistribution binaire. Ce code à été retiré depuis la
version 0.90-pre1 et le fichier résultant divx_vbr.c qui est
dérivé des sources OpenDivX à été placé sous GPL par ses auteurs au moment de la
version 0.90pre9. Vous êtes maintenant invité à créer des paquetages binaires si vous
en avez l'utilité.
D'autres impératifs pour la redistribution étaient les optimisations de compilation
pour l'architecture binaire. MPlayer supporte maintenant
la détection CPU (spécifiez l'option
à la configuration). Elle est désactivée par défaut parce quelle implique un petit
sacrifice de vitesse, mais il est maintenant possible de créer des binaires qui
fonctionneront sur les différents membres de la famille de CPU Intel.
nVidia
Nous n'aimons pas le fait que nVidia ne
fournisse que des pilotes binaires (à utiliser avec XFree86), qui sont souvent bogués.
Nous avons eu de nombreux rapports sur
mplayer-users
à propos de problèmes relatif à ces pilotes closed-source et à leur piètre qualité,
leur instabilité et le piètre support utilisateur et expert. Voici un exemple tiré du
Forum nVidia Linux.
Beaucoup de ces problèmes continuent de ce répéter. Nous avons contacté nVidia
récemment, et ils nous ont dit que ces bogues n'existaient pas, que l'instabilité
était causée par de mauvais chips AGP, et qu'ils n'avaient pas reçu de rapports de
bogues (comme la ligne violette). Donc si vous avez un problème avec votre carte
nVidia, nous vous conseillons de mettre à jour le pilote nVidia et/ou d'acheter une
nouvelle carte mère ou de demander à nVidia de fournir des pilotes open-source. Dans
tous les cas, si vous utilisez les pilotes binaires nVidia et rencontrez des problèmes
liés, soyez conscient que vous ne recevrez que peu d'aide de notre part car nous avons
trop peu de pouvoir pour améliorer les choses.
Joe Barr
Joe Barr est devenu tristement célèbre pour avoir écrit une moins-que-favorable
critique de MPlayer. Il a trouvé MPlayer
difficile à installer, mais là encore ce n'est pas un passionné de la
lecture de documentation.
Il a également conclu que les développeurs n'étaient pas amicaux et que la documentation
était incomplète et insultante. Vous êtes seul juge. Il à ensuite mentionné négativement
MPlayer dans ses
10 prédictions Linux pour 2002.
Puis dans une
critique de Xine
il a continué d'alimenter la controverse. Ironiquement à la fin de cet article il cite
son échange avec Günter Bartsch, l'auteur original de Xine,
qui résume parfaitement la situation:
Toutefois, il a ajouté qu'il avait été "surpris" par mon papier à propos de MPlayer
et pensait que c'était déloyal, me rappelant que c'est un projet de logiciel libre.
"Si vous ne l'aimez pas," à dit Bartsch, "vous êtes libre de ne pas l'utiliser."
Il ne réponds pas à nos courriers. Son éditeur ne réponds pas à nos courriers. Voici
quelques citations de différentes personnes à propos de Joe Barr, pour que vous
puissiez vous faire votre propre opinion:
Marc Rassbach a
quelque chose à dire
à propos de l'homme.
Vous devriez tous vous rappeler la LinuxWorld 2000, quand il prétendait que Linus T
avait dit que 'FreeBSD n'est qu'une poignée de programmeurs'. Linus n'a RIEN dit de tel.
Quand Joe à été contacté là-dessus, sa réaction a été de traiter les supporters de BSD
de trous du cul et de connards.
Une citation
de Robert Munro sur la liste de diffusion
mplayer-users:
Il est intéressant, mais pas très bon pour éviter, um... la controverse. Joe Barr était
un des habitués du forum Canopus de Will Zachmann sur Compuserve, il y a des années de
ça. C'était alors un défenseur d'OS/2 (dont j'étais fan moi aussi).
Il avait l'habitude d'exagérer, d'insulter les gens, et je suppose qu'il a dû avoir des
moments difficiles, alors. Il en à tiré une certaine maturité, à en juger par ces
derniers papiers. L'humour modérément subtil n'était pas son fort à cette époque, mais
alors pas du tout.