GCC 3.0

Posté par  (site web personnel) . Modéré par oliv.
Étiquettes :
0
18
juin
2001
GNU
La version tant attendue de GCC, la 3.0 finale vient enfin de sortir. Beaucoup d'optimisations, de correctifs de bogues, de nouvelles plates-formes supportées (dont IA-64), ainsi que l'ajout du support ISO C99 et ISO C++. De plus la compilateur Java (GCJ) fait maintenant partie intégrale de GCC.

Dispo dans toutes les bonnes crémeries locales.

Aller plus loin

  • # Problème

    Posté par  . Évalué à 1.

    Rassurez moi ; j'ai entendu parler des problèmes de compilation avec gcc 2.96 présent notamment sur redhat et mdk ; certains progs ne compilaient qu'avec le 2.95 ; est ce que là ça va être le même bordel ? Quand les distribs auront adopté le gcc 3 par défaut, est ce qu'il faudra vérifier si le programme est "gcc 3 compliance" ?
    Merci

    • [^] # Re: Problème

      Posté par  (site web personnel) . Évalué à 1.

      Comme d'hab, oui a toutes tes questions. Juste notons que la 2.96 etait une version experimentale.

      • [^] # ...version experimentale

        Posté par  . Évalué à 1.

        Si je me souviens bien, cette version n'était pas supportée par les développeurs de gcc...

        • [^] # Re: ...version experimentale

          Posté par  . Évalué à 1.

          C'était une version de développement vers gcc 3, meme pas numérotée 2.96 dans le cvs me semble-t-il (meme si c'était la numérotation logique). Des distributions Linux ont décidé de l'utiliser en la nommant 2.96, mais ca n'a jamais été une distribution gcc officielle.

        • [^] # ...version effectivement experimentale

          Posté par  . Évalué à 1.

          d'ou des trolls à n'en plus finir... La RedHat s'en est pris plein la tête...

          Le pire, c'est surement l'auteur de mplayer (un player avi-divx-mpeg) qui a configuré son ./configure pour refuser le gcc 2.96, ou si on tape --ignore-gcc-version (qqchose dans le genre) affiche "inutile de faire un bug-report"...

          Bref, une bonne nouvelle...

          • [^] # Re: ...version effectivement experimentale

            Posté par  . Évalué à 1.

            C'est pas uniquement pour troller. (et en plus, MPlayer refuse aussi le 2.91 par exemple). En fait, il est écrit dans le FAQ que la 2.96 ne compile pas le code mmx/3dnow.. J'ai du downgrader en 2.95 sur la mandrake où j'essayais.

      • [^] # Re: Problème

        Posté par  . Évalué à 1.

        Donc si je veux me faire un petit LFS, il vaut mieux que je prenne gcc 2.95 ?
        Et recompiler tout mes progs (avec la version 3.0) quand ils seront à jour ?

        • [^] # Re: Problème

          Posté par  (site web personnel) . Évalué à 1.

          « Donc si je veux me faire un petit LFS, il vaut mieux que je prenne gcc 2.95 ? »

          Non.
          Il me semble que dans les derniers kernel (à partir de 2.4.2) les incompatibilités avec gcc3 ont été résolues.

          En dehors du noyau, qui est évidemment très lié au compilateur (à cause de la taille des types notamment), il n'y a aucun problème. GCC3 compile très bien.
          La seule chose sera parfois d'aller modifier à la main quelques Makefiles mal faits.

          • [^] # Re: Problème

            Posté par  . Évalué à 1.

            Merçi :)

          • [^] # Re: Problème

            Posté par  . Évalué à 0.

            Moi, quand je compile modkeyboard.c avec gcc 3.0, mon clavier se blo

            • [^] # Re: Problème

              Posté par  . Évalué à 0.

              Moi, j'utilise un noyau linux écrit en perl. Ca marche bien.

            • [^] # Re: Problème

              Posté par  . Évalué à 0.

              J'ai rien contre le fait qu'on reprenne des news déjà passées sur /. surtout pour un truc aussi important, mais c'est pas vraiment la peine de refaire les même trolls en dessous, quand même.

              http://slashdot.org/comments.pl?sid=01/06/14/2322251&threshold=(...)

              • [^] # Re: Problème

                Posté par  (site web personnel) . Évalué à 1.

                Rhalalala, encore un qui ne fait pas assez de tribune ;-)

                Les claviers qui se blo, c'est un peu comme les clients irc ecrits en PERL, Plop, wmcoincoin, Ingrid, la femme à Christian, la Guinness, la c[an|on|oin]coillotte, les photons qui prennent le TGV, le Nutella, le TCPOT, et tous ceux que j'oublie...

                Pour connaitre tout ça, pour passer d'excellentes journées en compagnie de non moins formidables personnes, une seule adresse :
                http://linuxfr.org/board(...)

                • [^] # Vive la Tribune Libre - Ne pas lire - Aucun Interet

                  Posté par  (site web personnel) . Évalué à -1.

                  Et oui.
                  Tu as tout de meme oublié FRED et Fabien !!!
                  Bref.

                  Merci de me dire que je suis formidable, je suis touché. Tu es mon ami.

                  Pour tous ceux qui lisent ce message bien que posté en -1, rejoignez nous et faites les moules sur la tribune.
                  Si vous ne savez pas ce que c'est qu'une moule de tribune, posez la question sur la tribune. Une moule sera toujours la pour vous répondre.

                  Bref, ceci n'a aucun interet.
                  Merci Daemo0on. Bon, je retourne sur la tribune moi.

                  JR - Animateur de tribune : 7h45 - 17h00 du Lundi au Vendredi.

          • [^] # Re: Problème

            Posté par  . Évalué à 1.

            de toute facon il vaut mieux compiler son kernel avec egcs

            • [^] # Re: Problème

              Posté par  (site web personnel) . Évalué à 1.

              Euh, c'est un troll ?

              Gcc veut maintenant dire "GNU Compiler Collection" et sur http://gcc.gnu.org/(...) on apprend que :

              "In April 1999, the egcs steering committee was appointed by the FSF as the official GNU maintainer for GCC"

              Donc....

              • [^] # Re: Problème

                Posté par  . Évalué à 1.

                Non ce n'est pas un troll, absolument pas, c'est une recommandation officielle.

              • [^] # Re: Problème

                Posté par  . Évalué à 0.

                Sais tu au moins ce qu'est egcs ?
                Ah puis voila de la lecture
                - > /usr/src/linux/Documentation/Changes
                The recommended compiler for the kernel is egcs 1.1.2 (gcc 2.91.66), and it
                should be used when you need absolute stability. You may use gcc 2.95.x
                instead if you wish, although it may cause problems. Later versions of gcc
                have not received much testing for Linux kernel compilation, and there are
                almost certainly bugs (mainly, but not exclusively, in the kernel) that
                will need to be fixed in order to use these compilers. In any case, using
                pgcc instead of egcs or plain gcc is just asking for trouble.

          • [^] # Re: Problème

            Posté par  . Évalué à 1.

            > En dehors du noyau, qui est évidemment très lié au compilateur (à cause de la taille des types notamment), il n'y a aucun problème. GCC3 compile très bien.
            > La seule chose sera parfois d'aller modifier à la main quelques Makefiles mal faits.

            Bof. Sur un gros projet en C++ (où nous avions commencé par des ennuis avec egcs 2.91.6...), le "portage" sous 2.95.2 avait déjà pris du temps (ISO C++ compliance, le parser est plus sévère, c'est bien mais c'est chiant faut tout corriger), et là pour rigoler, alors que tout passe très bien sous 2.95.2 (Debian ou Mdk), on a essayé de recompiler avec 2.96 sous Mdk et déjà ça ne passait plus... Alors la 3.0 je n'ose pas imaginer.
            C'est vraiment chiant de devoir réécrire du code (et pas juste des Makefile) en fonction du compilateur, alors qu'on ne change même pas de plate-forme!...

            • [^] # Re: Problème

              Posté par  . Évalué à 1.

              Et si tu écrivais du code propre et qui respecte les standards ?
              Bon je sais parfois on est pressé, c'est chiant, mais quand il faut tout réécrire on se dit qu'on aurait du éviter de faire le goret au premier coup...
              Désolé pour mon aggressivité, mais j'ai lu des codes tellement crades (en C comme en Perl) que je me demande comment on peut donner des trucs comme ça à débugguer au lieu de nous faire tout réécrire from scratch ;-)

              • [^] # Re: Problème

                Posté par  . Évalué à 0.

                >Et si tu écrivais du code propre et qui respecte les standards ?

                La chose serait plus facile si les compilateurs eux même respectaient les standards, hein...

                • [^] # Re: Problème

                  Posté par  (site web personnel) . Évalué à 1.

                  <it> « La chose serait plus facile si les compilateurs eux même respectaient les standards, hein. » </it>

                  Justement, gcc 3.0 respecte mieux les standards que les versions antérieures (en tout cas pour C et C++)

                • [^] # Re: Problème

                  Posté par  . Évalué à 1.

                  La chose serait plus facile si les compilateurs eux même respectaient les standards, hein...

                  Faut pas se plaindre quand on utilise des snapshots de compilos en cours de développement.

                  • [^] # Re: Problème

                    Posté par  . Évalué à 0.

                    ah, gcc a toujours été en snapshot alors :-)

              • [^] # HéHé...

                Posté par  (site web personnel) . Évalué à 1.

                Alors bmc ?
                <troll status=private>
                Tu reconnais enfin que le PERL, c'est crade ?
                </troll>

                • [^] # Re: HéHé...

                  Posté par  . Évalué à -1.

                  Des gens pensent encore le contraire ?

              • [^] # Re: Problème

                Posté par  . Évalué à 1.

                Ah mais le code est propre... Trop propre, même! Stroustrup à la main! Et je ne parle pas que des choses qui ne sont pas encore ou mal implémentées mais qui figurent déjà dans le standard.
                Simplement le code propre ça ne passe pas toujours, alors il faut corriger pour tenir compte des bugs
                du compilo ("c'est du libre, on ne peut pas s'occuper de tous vos bugs" m'a répondu un développeur egcs alors que je lui signalais un paquet de bugs == comportement observé différent de ce que stipule la doc d'egcs), de la lib c++ (choses qui _devraient_ être réentrantes, etc.).

                C'est libre donc on ne peut pas trop en demander, ok.
                Mais c'est quand même chiant de se faire presque insulter quand on rapporte des bugs, et de devoir passer des heures à comprendre que c'est l'outil qui déconne et pas le code écrit. Avec EGCS, nous avons appris à nos dépends que ce n'est pas parce que c'est codé/documenté que c'est bien fait/implémenté, voilà.

                Donc je retourne la question : et s'ils faisaient un compilo et une lib c++ propres qui respectent les standards, peut-être en sortant moins souvent une nouvelle version...

  • # ... les bonnes crémeries locales

    Posté par  . Évalué à 1.

    J'espère que les paquets Debian ne vont pas trop tarder... a moins que quelqu'un ait une URL qqpart?

    • [^] # Re: ... les bonnes crémeries locales

      Posté par  . Évalué à 0.

      En général ca ne traine pas, c'est une des mises à jour prioritaires dans testing. Bon évidemment, mettre gcc 3 c'est pas comme 2.95.3 -> 2.95.4, et testing n'est pas unstable.
      Mais si ta question (URL) portait sur des paquets non officiels, je pense que gcc arrivera plutot directement dans testing/unstable que dans un répertoire perso.

      • [^] # Re: ... les bonnes crémeries locales

        Posté par  . Évalué à 1.

        les 3.0 de la cvs étaient déja dans unstable/testing (paquet gcc3.0 je crois)

        faire un 'dpkg -l "gcc*"' pour voir la liste.

        • [^] # Re: ... les bonnes crémeries locales

          Posté par  (site web personnel) . Évalué à 1.

          Ouais, je vais quand même attendre que les mainteneurs recompilent au moins les softs utilisant la libstdc++, histoire de pouvoir virer gcc-2.95 (inutile de garder du poids mort) et je vais aussi attendre que quelqu'un de plus téméraire que moi annonce que tout (y compris le kernel) se recompile bien avec la nouvelle mouture. « Point ne sert de courir, [...] ».

          Envoyé depuis mon PDP 11/70

    • [^] # Re: ... les bonnes crémeries locales

      Posté par  . Évalué à 1.

      Les rpm Mandrake sont dispos dans le rép mandrake_devel/contrib

  • # un petit test ?

    Posté par  . Évalué à 1.

    Un petit test que j'avais fait avec le compilo livré avec la Mandrake 8.0 :
    juste une petite recompilation de xanim et apreès essayer de jouer un mpeg : boum ...

    après insultes diverses et variées ainsi q'une ou deux recompilations, je mesuis apperçut qu'avec la version officielle stable ça passait nickel mais pas avec le machin CVS de mdk
    Alors c'est pas un troll (même si c'est bien immité). Mais ma question c'est est-ce que qqun a fait un test de ce genre et si oui est-ce corrigé dans la nouvelle mouture ?

    voila ma question à 0,002 ?

    • [^] # Re: un petit test ?

      Posté par  . Évalué à 0.

      dans la nouvelle mouture de quoi?
      de xanim ou de gcc?

      C'est la question que tu devrais te poser. xanim est un vieux programme, dont des parties ne doivent certainement pas respecter les standards. le compilo de Mandrake (en gros, le même que RedHat) est une version plus stricte, qui ne te laissera pas passer un mauvais code. Regarde dans un message plus haut le lien vers la page écrite par Bero sur gcc 2.96

      Bref, c'est peut-être la faute de xanim s'il ne compile pas. Et dans ce cas, il ne compilera pas avec gcc 3.0, ni avec aucun de ses successeurs.

    • [^] # Re: un petit test ?

      Posté par  . Évalué à 0.

      t'es au courant qu'on a recompile toute une distro avec ce compilo-la?

      d'ailleurs je me demande ce que tu veux dire par 'recompiler' xanim puisqu'on le fournit dans la 8.0 et qu'il marche tres bien. curieux non.

      gcmdk

      • [^] # Re: un petit test ?

        Posté par  . Évalué à 1.

        Oui je suis au courrant que l'on a recompilé toute une distribution avec puisque je l'utilise.

        Mais je persiste et signe en disant que justement, la version officielle elle plante lamentablement chez moi. d'où mon recompiler.

        Recompiler : action de régénérer les binaires à partir des sources. <-- ma définition a moi ! Na!

        • [^] # Re: un petit test ?

          Posté par  . Évalué à 0.

          J'ai la meme definition et ca marche ici, de meme que pour les dizaines de types de cooker. De la a dire que t'as du te chier dessus sur ta machine en voulant jouer au malin, y'a qu'un pas que je ne franchirai pas par pudeur :-).

          gcmdk

          • [^] # Re: un petit test ?

            Posté par  . Évalué à 1.

            Bof, dans ce cas là évidamment ...

            Non mais sans rire, et honnêtement, j'y ai passé du temps sur ce truc alors je m'explique :

            - dans tous les cas ça compile !
            - seleulement à l'exécution de xanim avec un fichier mpeg boum (core dump). Cela arrive avec le rpm "officiel" ou avec un autre reconstruit à partir du rpm source avec la version du gcc officiel de l MDK 8
            - si le compilateur utilisé pour reconstruire le xanim est kgcc ou bien la version de la MDK 7.x (2 en l'occurence) l'éxécution se déroule normalement (l'animation est vimible).
            - oui j'ai poussé l'investigation plus loin :
            le problème proviens de l'initialisation d'un tableau de structure à l'aide d'une macro. Tableaudéclaré en variable globale est alloué juste avant.
            Maintenant tu peux penser que le code de xanim est mal écrit ou quoi que ce soit. S'auf que sur cette partie là je ne vois vraiement rien d'extraordinaire. Pour info la fonction incriminé débute à la ligne 1063 du fichier xa_mpg.c et elle est appelé par la fonction à la ligne 1458.
            Voila.
            Donc vouloir jouer au malin je vois pas trop comment. Puisque au début tout ce que j'ai fait c'est installer un rpm et là il doit pas y avoir trop de risques à le faire (le malin).
            Si un autre truc justement le rpm de xanim il est sur quel CD de la MDK8, j'ai récupéré celui du site ftp ?

  • # Le sujet est trop compliqué...

    Posté par  . Évalué à 0.

    Autant n'importe quelle news naze sur gnome/kde, ou mdk déclenche une avalanche de posts de petit péteux qui se prétendent informaticiens (ou mieux nerds), autant une info sur un truc bien pointu laisse de marbre la communauté des branleurs. Et encore, en lisant les posts, on est rapidement déçu : pas d'avis sur les optimisations, ou les comparaisons avec les compilos payants, ou les perfs sur java...

    Pourtant, linuxfr est le meilleur portail linux francophone, tant qu'on ne lit pas les commentaires. C'est un peu le genre de critique qui ressort de ce type de portail à la slashdot (je suis con j'aurais du écrire /. et rajouter une ligne en perl pour montrer que je ne suis pas n'importe qui...)

    Quelles sont les solutions ?
    - séparer les trolls comme on dit des vrais commentaires
    - proposer un forum pour en découdre ou se marrer tout en étant très pointilleux sur les commentaires des news
    - revoir le système de score, déjà très bon mais lui aussi pollué par tous les glands qui se prennent pour le fils spirituel de Alan Cox
    - ...

    • [^] # Re: Le sujet est trop compliqué...

      Posté par  . Évalué à 1.

      Commence par t'authentifier: tu auras l'air moins rigolo...

      C'est l'hôpital qui se fout de la Charité.

      PK

    • [^] # Re: Le sujet est trop compliqué...

      Posté par  (Mastodon) . Évalué à 1.

      - ...

      Et ça, c'est en provenance directe de la charte de f.m.b.l :)

    • [^] # Re: Le sujet est trop compliqué...

      Posté par  . Évalué à 1.

      Et encore, en lisant les posts, on est rapidement déçu : pas d'avis sur les optimisations, ou les comparaisons avec les compilos payants, ou les perfs sur java...

      Où as-tu lancé une discussion sur ces sujets ?

    • [^] # Re: Le sujet est trop compliqué...

      Posté par  (site web personnel) . Évalué à 1.

      Eclaire-moi de ta lumière toi qui est si fort.

      Tu as dû développer un générateur de conneries automatique pour dégueuler autant d'insultes.

      Selon toi la plupart des personnes qui vont sur linuxfr sont des crétins imbéciles qui ne connaissent rien à l'informatique ce qui ne les empêche pas de se prendre pour des dieux.

      Et ben on se demande ce que tu fous encore là. Va donc faire profiter de ta science les lecteurs de 01 info.

      • [^] # Re: Le sujet est trop compliqué...

        Posté par  . Évalué à -1.

        "Tu as dû développer un générateur de conneries automatique"

        Mais nooon, il est juste devellopeur Netscape 6 ;-)

        On l'avait presque perdu, mais il est de retour...

    • [^] # Re: Le sujet est trop compliqué...

      Posté par  . Évalué à 0.

      Si tu veux des vrais questions :

      JAVA ???

      Est-ce que ça veut dire que je vais pouvoir faire un binaire à partir des sources de Freenet ?
      Ce que je veux dire par là est : je prends un programme java qui a tendance à exploiter plein de classes d'un environnement JDK de facture récente (dans mon exemple, tout ce qui concerne le réseau), ça peut le faire ? Où est-ce que ce n'est qu'un compilateur, et qu'il va falloir attendre que soit créé autour les librairies nécessaires à une utilisation réelle ?

      (extrait des commentaires de la même news sur toolinux)

  • # gcc 3.0 et les autres...

    Posté par  . Évalué à 0.

    quelqu'un a t'il tester gcc 3.0 sur une autre plateforme que 80x86 ? est t'il toujours aussi pourri sur Alpha par exemple ?

    Si quelqu'un a des benchs...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.