Sortie de GCC 3.3.1

Posté par  (site web personnel) . Modéré par Pascal Terjan.
Étiquettes :
0
12
août
2003
GNU
GCC, la suite de compilateurs du projet GNU (C, C++, Objective-C, Fortran, Java et Ada), vient de sortir en version 3.3.1. Il s'agit d'une version de maintenance avec des corrections de bogues par rapport à la version 3.3 précédente (ce sera aussi le cas pour la future 3.3.2), en attendant la prometteuse version 3.4 et son lot de nouveautés.

Plus inattendue, la présence d'un README.SCO dans l'archive. Il contient une explication de la FSF à propos des accusations de SCO, non prouvées, et de leur demande d'obliger le paiement des licences, en violation de la GPL. Malgré les demandes reçues par la FSF de ne plus supporter SCO Unix avec GCC, et pour ne pas pénaliser les utilisateurs de ce système, il a été choisi de conserver le support, pour l'instant. Les utilisateurs de SCO Unix sont invités à faire entendre leurs protestations auprès de SCO.

Aller plus loin

  • # Re: Sortie de GCC 3.3.1

    Posté par  . Évalué à 8.

    Le boycott du système d'exploitation est surement le moyen de pression le plus efficace contre SCO.
    Ce moyen est surement inattendu de la part de SCO et surement plus efficace dans le temps que les brevets et autre combats juridiques qui sont de l'ordre de quelques années.


    Le libre peut avoir un réel moyen de pression en faisant priviléger d'autres OS...
    • [^] # Re: Sortie de GCC 3.3.1

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

      Bah je pense que SCO prevoit que quasiment l'integralite de ses revenus ces prochaines années viendra des proc et des licenses Linux...
      Ca leur fera pas grand mal si leur OS meurt alors qu'ils gagnent un procès. Si ils le perdent ils sont morts de toute façon...
    • [^] # Re: Sortie de GCC 3.3.1

      Posté par  . Évalué à 10.

      Pas du tout efface.
      La décision de la FSF est très sage : SCO étant devenue une boîte d'avocats, ce n'est pas l'absence des dernières versions de (très bons) logiciels sur leurs machines dépassées qui va les géner. Par contre les quelques utilisateurs qui restent sur de tels machines le seraient effectivement.
      La FSF n'adopte donc pas la tactique des majors du disque d'emmerder les gens honnêtes lorsqu'elle est attaquée par une bande de crétins.

      Par contre le README.SCO et les prises de consciences && protestations que ça peut engendrer sont AMHA une bonne idée.
      • [^] # Re: Sortie de GCC 3.3.1

        Posté par  . Évalué à 9.

        euh, sauf qu'a priori c'est la FSF qui voulait boycotter, et c'est la team gcc qui a dit non...
        • [^] # Re: Sortie de GCC 3.3.1

          Posté par  . Évalué à 2.

          tu as des liens sur ce que tu avances svp ? juste par curiosité
          • [^] # Re: Sortie de GCC 3.3.1

            Posté par  . Évalué à 3.

            C'est ce qui est écrit dans le readme.sco. Le lien est dans la dépêche.
            • [^] # Re: Sortie de GCC 3.3.1

              Posté par  . Évalué à 5.

              We have been urged to drop support for SCO Unix
              Ils ne disent pas par qui !
              Ca peut être par la FSF, mais aussi par des libristes mécontents : il suffit de regarder slashdot, SCO y a largement détroné MS comme société la plus haïe et cette idée de boycotter SCO y est souvent avancée.
              Bon de toute façon ce n'est pas trop important.
              • [^] # Re: Sortie de GCC 3.3.1

                Posté par  . Évalué à 9.

                Ils ne disent pas par qui !
                Par la FSF. Lis le paragraphe en entier.

                Bon de toute façon ce n'est pas trop important.
                Exactement. Tu as raison et c'est aussi ce qu'ils pensent.
                C'est pour ça qu'ils ne pointent pas la FSF du doigt parce qu'alors il faudrait aussi mentionner les libristes acharnés,... et ils ne veulent apparemment pas lancer de polémique.
                L'important pour GCC est d'affirmer leur soutient aux utilisateurs avant tout, même s'ils utilisent une plate-forme controversée.
                Je trouve leur position raisonnable et respectueuse, et donc respectable.
            • [^] # Re: Sortie de GCC 3.3.1

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

              The Free Software Foundation's
              overriding goal is to protect the freedom of the free software
              community, including developers and users, but we also want to serve
              users.


              Ils semblent parler au nom de la FSF, pas au nom de l'équipe GCC. Et ils ne disent pas qui leur a demandé de ne plus supporter SCO Unix.
              • [^] # Re: Sortie de GCC 3.3.1

                Posté par  . Évalué à 2.

                personnellement, je comprends dans cette phrase qu'ils ne parlent pas au nom de la FSF justement
              • [^] # Re: Sortie de GCC 3.3.1

                Posté par  . Évalué à 3.

                "we" == GCC
                "FSF" == eux, ils

                Ils ne parlent pas au nom de la FSF, ce serait incorrect et impoli.
                C'est un message de GCC dans lequel ils clarifient leur position et mentionnent la position de la FSF.
                • [^] # Re: Sortie de GCC 3.3.1

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

                  D'après le lien donné par ptit_tux plus haut, le README.SCO a été proposé par la FSF, en tout cas (The FSF has asked me to check in this file on both the branch and the mainline.). Effectivement l'usage de "we" peut être interprété d'une manière ou de l'autre, et ce n'est pas très important.
                  • [^] # Re: Sortie de GCC 3.3.1

                    Posté par  . Évalué à 1.

                    Plus spécifiquement l'ajout a été demandé par Richard Stallman et Eben Moglen (voir le patch du changelog) . Bref on peut pratiquement affirmer que c'est la FSF.
                  • [^] # Re: Sortie de GCC 3.3.1

                    Posté par  . Évalué à 2.

                    Juste pour ajouter que quand on connait les auteurs du README.SCO, le "we" devient tout de suite plus claire :-)
            • [^] # Re: Sortie de GCC 3.3.1

              Posté par  . Évalué à -1.

              > C'est ce qui est écrit dans le readme.sco

              J'ai pas vu ça :
              The Free Software Foundation's overriding goal is to protect the freedom of the free software community, including developers and users, but we also want to serve users.

              De plus :
              We will have a further announcement concerning continuing support of SCO Unix
              by GCC before our next release.


              C'est "We" et non "The Free Software Foundation".

              J'ai vu sur la mailing-list gcc, que certains développeurs de gcc étaient assez chaud par rapport à SCO (le début du thread) :
              http://gcc.gnu.org/ml/gcc/2003-07/msg01564.html(...)
  • # Objective-C (++)

    Posté par  . Évalué à 7.

    Les patches d'Apple pour le support d'Objective-C & Objective-C++ (un hack qui permet d'utiliser de manière transparente les objets C++ en objective-C ou vice-Versailles) ne seront pas apparemment intégrés dans cette version.
    Dommage pour Nicolas Roard, Fabien Vallon et les autres gourous GNUstep ;-)
    • [^] # Re: Objective-C (++)

      Posté par  . Évalué à 4.

      On espere tres fort pour la 3.4 :-)

      Comme ca on aura peut etre un WebCore pour GNUstep. En passant, la nouvelle version de OmniWeb utilise dorenavant WebCore et JavaScriptCore.
      • [^] # Re: Objective-C (++)

        Posté par  . Évalué à 2.

        Non, ça ne sera très probablement pas pour la 3.4. Dans la 3.4, les améliorations d'Apple concernant l'ObjC seront apportées, mais ce qui concerne l'ObjC++ ne devrait au mieux être présent que dans la 3.5.
        La raison en est simple : la version 3.4 a déjà passé le stage 1, c'est-à-dire le moment (si j'ai bien suivi la façon dont est géré le processus de décision pour gcc) où l'on décide ce qu'on va rajouter dans cette version. C'est trop tard donc pour y inclure l'ObjC++.
    • [^] # Re: Objective-C (++)

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

      > Vice-Versailles ?
      comme c'est original !
      vice-versa
  • # Re: Sortie de GCC 3.3.1

    Posté par  . Évalué à 7.

    Avec tout cela, on parle même plus de la polemique sur les performances de GCC3 ! On tombe bien bas :-)
  • # Re: Sortie de GCC 3.3.1

    Posté par  . Évalué à -1.

    Es-ce qu'ils ont encore changé les ABI ou ils se sont enfin calmé sur ces conneries ?
  • # Re: Sortie de GCC 3.3.1

    Posté par  . Évalué à 3.

    moi je dis que c'est vrai que Linux comporte des lignes de SCO unix.
    ouais, y'en a meme des milliers :
    je vous en donne seulement 2 qui ont été dupliquées des tas de fois :
    1ère ligne : {
    2ème ligne : }
    mais par contre dans MultiDeskOS y'en a pas !,
    pas fou l'autre, il a mis
    1ère ligne : begin
    2ème ligne : end;
    il ne prend pas de risques d'être attaqué par SCO, pas folle la guêpe !
  • # Re: Sortie de GCC 3.3.1

    Posté par  . Évalué à -1.

    Tient ben j'en profite pour poser une question :
    j'ai un problème pour porter du code C++ de windows vers unix avec gcc 3.2.3, ça conserne les iterators de map de la stl, voilà l'erreur :
    In member function `void
    no match for `
    std::_Rb_tree_iterator<std::pair<const _bstr_t, maClasse*>,
    std::pair<const _bstr_t, maClasse*>&, std::pair<const _bstr_t,
    maClasse*>*>& = void' operator
    /usr/local/include/c++/3.2.3/bits/stl_tree.h:184: candidates are:
    std::_Rb_tree_iterator<std::pair<const _bstr_t, maClasse*>,
    std::pair<const _bstr_t, maClasse*>&, std::pair<const _bstr_t,
    maClasse*>*>& std::_Rb_tree_iterator<std::pair<const _bstr_t,
    maClasse*>, std::pair<const _bstr_t, maClasse*>&,
    std::pair<const _bstr_t, maClasse*>*>::operator=(const
    std::_Rb_tree_iterator<std::pair<const _bstr_t, maClasse*>,
    std::pair<const _bstr_t, maClasse*>&, std::pair<const _bstr_t,
    maClasse*>*>&)

    Si ça vous dit quelque chose et que vous pouvez apporter une réponse à ma question, je serais super content :o)
    • [^] # Re: Sortie de GCC 3.3.1

      Posté par  . Évalué à 2.

      Bon même si c'est pas le lieu pour répondre :)
      J'ai déja eu ce type de message dans le cas ou je faisais de l'héritage multiple sur des classes instantiable, il ne savait pas quelle fonction choisir (alors qu'à priori ce sont les mêmes !)
      Donc il faut que tu spécifie l'une des classes desquelles tu hérites.
      Si tu n'as pas fait un héritage multiple, ben je sais pas ...
      Caeies, onnepeutplusclair :)
      • [^] # Re: Sortie de GCC 3.3.1

        Posté par  . Évalué à 2.

        Merci pour ton aide.

        > Bon même si c'est pas le lieu pour répondre :)
        Personnellement, ça ne me choque pas plus que ça :o). Après tout, DLFP ça peut aussi être utile et puis on n'est pas si hors-sujet que ça :).
    • [^] # Re: Sortie de GCC 3.3.1

      Posté par  . Évalué à 1.

      Je vois... il y en a en fait plusieurs problèmes:
      * le C++ n'est pas fait pour faire de l'objet, ça se saurait depuis le temps qu'il existe; il faut plutôt utiliser Eiffel, Java ou Objective C;
      * la STL, pour qu'elle marche bien, il faudrait la porter dans un langage objet, en l'état il ne faut pas compter dessus, voir problème précédent;
      * de toutes façons, on ne porte pas du code depuis une plateforme impure , on le réécrit complètement!

      Où ça un troll?!
    • [^] # Re: Sortie de GCC 3.3.1

      Posté par  . Évalué à 1.

      Je pencherai pour un probleme a l'utilisation : c'est quoi la ligne ou il y a ton probleme de compil ?

      Il te dit qu'il essaie de chercher un operateur du style
      Iterator::operator =(void)
      alors qu'il ne connait que :
      Iterator& Iterator::operator=(const Iterator &)

      Bref, ton membre de droite a l'air d'etre a l'ouest dans une expression comme
      Iterator it = expression
      • [^] # Re: Sortie de GCC 3.3.1

        Posté par  . Évalué à 3.

        ton membre de droite a l'air d'etre a l'ouest

        forcément y a une erreur
      • [^] # Re: Sortie de GCC 3.3.1

        Posté par  . Évalué à 1.

        La ligne ou il y a le problème est la suivante :

        iteratorDeMaClasse = mapDeMaClasse.erase(iteratorDeMaClasse);

        Le problème ce situe apparament sur la méthode erase qui retour un iterator sur l'objet suivant de la liste alors qu'avec la glibstdc++ elle ne retourne rien. En tout cas merci pour ton aide.
        • [^] # Re: Sortie de GCC 3.3.1

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

          http://groups.google.com/groups?q=map+erase&hl=en&lr=&i(...)

          Page 491 of the standard gives three overloaded members 'erase' for
          std:map:
          void erase(iterator position);
          size_type erase(const key_type& x);
          void erase(iterator first, iterator last);
          A map is an associative container, and page 466 gives requirements for
          associative containers. There are three 'erase's, which are the same as
          the above but ordered 2,1,3.

          According to the text on page 490, a map also meets the requirements of a
          container and of a reversible container (subclause 23.1) and "most
          operations described in (23.1.2) for unique keys. This means that a map
          supports the a_uniq operations but not the a_eq operations."

          There is an erase member function that returns an iterator, but it is for
          sequence containers (vector, list, deque, page 462, subclause 23.1.1),
          not maps.
          • [^] # Re: Sortie de GCC 3.3.1

            Posté par  . Évalué à 2.

            Good link, thank 's.
            donc, pour parcourir une map et y supprimer des éléments, je suis obligé de faire :

            monTypeDeMap::iterator monIterator1;
            monTypeDeMap::iterator monIterator2;

            monIterator1 = maMap.begin();
            while (monIterator1 != maMap.end()){
            if (...){
            monIterator2 = monIterator1++;
            maMap.erase(monIterator2);
            }
            else
            monIterator1++;
            }

            C'est un peu lourd :-(
            • [^] # Re: Sortie de GCC 3.3.1

              Posté par  . Évalué à 3.

              Tout s'explique ! :-)

              Deux choses :
              1- la STL sous windows n'est pas standard, donc lorsque tu fais un port tu peux t'apercevoir que tu as utilise des trucs pas standard : utilise une implementation standard des STL comme la STLport par exemple.
              2 - evites de parcourir une map avec des iterateurs et de les effacer au fur et a mesure. En effet lorsque tu efface un iterateur d'un container, tu risques de modifier la structure du container, et donc tu invalides tes autres iterateurs : si tu fais des traitements avec des iterateurs non valide, tu vas voir apparaitre des bugs que tu auras du mal a localiser. (memoire corrompu entre autre)

              Dans le cas qui t'interresse, il vaut mieux que tu construise une deuxieme map avec les elements que tu souhaites garder, en dupliquant tes enregistrements. Ensuite tu n'as plus qu'a detruire ta premiere map.
              • [^] # Re: Sortie de GCC 3.3.1

                Posté par  . Évalué à 1.

                la STL sous windows n'est pas standard
                La STL founie avec Visual C++ vient en fait de DINKUMWARE. Pour citer leur page :
                " Needless to say, the Dinkum C++ Library is the only completely conforming option today. It easily outdistances Libstdc++ from Project Gnu, STLport, and the latest releases of the Rogue Wave library."
                Bon comme ça vient de leur site, on pourrait prendre ça pour de la pub, mais ça doit être vrai je pense car cette lib a bonne réputation.

                utilise une implementation standard des STL comme la STLport par exemple.
                Donc, en fait les problèmes de "standard compliance" ne viennent pas de la librarie directement mais plutôt du compilateur.
            • [^] # Re: Sortie de GCC 3.3.1

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

              Je ne suis pas sur, mais il me semble que std::map() n'est pas un conteneur dont les iterateurs restent valides après un erase(). Autrement dit quand tu effaces un élément d'une map, ça invalide tous les iterateurs sur cette map. J'insiste: je n'en suis pas sur, j'ai pas mes refs STL sous la main. D'ailleurs je te conseille :

              - Generic Programming and the STL. Matt Austern, ISBN 0201309564.
              - The C++ Standard Library : A Tutorial and Reference. Nicolai M. Josuttis. ISBN 0201379260.

              (plutôt le 2eme)

              tu trouvera des exemples sur comment faire ce que tu veux.

              C'est un peu lourd :-(

              C'est la STL. Au début je trouvais l'abstraction iterateurs/conteneurs/algorithmes géniale, depuis j'en suis un peu revenu. Ça permet de faire des trucs très sioux, mais ça complexifie aussi beaucoup trop des choses qui devraient être simples (comme celle ci).
              • [^] # Re: Sortie de GCC 3.3.1

                Posté par  . Évalué à 1.

                Aie, j'avais envisagé de l'implémenter ainsi :

                monTypeDeMap::iterator monIterator;

                monIterator = maMap.begin();
                while (monIterator != maMap.end()){
                if (...){
                maMap.erase(monIterator);
                }
                monIterator++;
                }


                ...mais à vous écouter ça n'a pas l'air d'être une bonne idée. J'ai testé sous windows et ça marche... autrement dit, ça ne m'inspire pas confiance du tout :o).


                C'est la STL. Au début je trouvais l'abstraction iterateurs/conteneurs/algorithmes géniale, depuis j'en suis un peu revenu. Ça permet de faire des trucs très sioux, mais ça complexifie aussi beaucoup trop des choses qui devraient être simples (comme celle ci).

                Je suis tout à fait d'accord, la STL c'est bien, en abuser ça craint.
                • [^] # Re: Sortie de GCC 3.3.1

                  Posté par  . Évalué à 0.

                  Tu peux peut-être te trouver un bon bouquin sur le sujet au lieu de poster ici ? ;)
  • # Commentaire supprimé

    Posté par  . Évalué à 7.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: fortran 95

      Posté par  . Évalué à 1.

      Malheureusement ça m'intéresse (bah oui, on ne choisit pas toujours son langage ...). Est-ce que tu aurais un lien quelconque vers une annonce ou quelque chose dans le genre?

Suivre le flux des commentaires

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