On Tue, 06 Sep 2005 22:34:32 +0200, Thierry B. wrote:
Voilà, une version qui date de mi-aout.
http://tontonth.free.fr/compil_openqm.txt
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
joli, non ?
Là, la perche est un peu grosse: utiliser un compilo notoirement buggé pour faire des tests, ce n'est pas forcément une très bonne idée...
R12y
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat:
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein...
je trouve que sur ce coup, ils n'ont pas assuré chez RH.
--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
helios
"R12y" a écrit dans le message de news:
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
"R12y" <mihamina.rakotomandimby@etu.univ-orleans.fr> a écrit dans le message
de news:pan.2005.09.06.23.49.16.720467@etu.univ-orleans.fr...
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat:
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein...
je trouve que sur ce coup, ils n'ont pas assuré chez RH.
pour info voici la procedure d'install pour openqm et une aide minimale
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
l'indien
On Wed, 07 Sep 2005 08:37:57 +0200, helios wrote:
"R12y" a écrit dans le message de news:
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier ne soit pas encore vraiment stabilisé...
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
Comme il est hors de question d'installer un programme qui ne compile pas proprement, cette "aide" n'a aucun intérêt pour moi.
On Wed, 07 Sep 2005 08:37:57 +0200, helios wrote:
"R12y" <mihamina.rakotomandimby@etu.univ-orleans.fr> a écrit dans le message
de news:pan.2005.09.06.23.49.16.720467@etu.univ-orleans.fr...
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat:
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein...
je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier
ne soit pas encore vraiment stabilisé...
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
Comme il est hors de question d'installer un programme qui ne compile pas
proprement, cette "aide" n'a aucun intérêt pour moi.
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier ne soit pas encore vraiment stabilisé...
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
Comme il est hors de question d'installer un programme qui ne compile pas proprement, cette "aide" n'a aucun intérêt pour moi.
helios
"l'indien" a écrit dans le message de news:
On Wed, 07 Sep 2005 08:37:57 +0200, helios wrote:
"R12y" a écrit dans le message
de news:
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement
buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier ne soit pas encore vraiment stabilisé...
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
Comme il est hors de question d'installer un programme qui ne compile pas proprement, cette "aide" n'a aucun intérêt pour moi.
c'est justement ce qui provoque des "bug" ne pas avoir installer les fichiers avant compilation comment veux tu que Gcc trouves les fichier et lib si tu les as pas mis la ou cela doit etre et comme cela doit etre
"l'indien" <l_indien_no_more_spams@magic.fr> a écrit dans le message de
news:pan.2005.09.07.21.42.34.860972@magic.fr...
On Wed, 07 Sep 2005 08:37:57 +0200, helios wrote:
"R12y" <mihamina.rakotomandimby@etu.univ-orleans.fr> a écrit dans le
message
de news:pan.2005.09.06.23.49.16.720467@etu.univ-orleans.fr...
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat:
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
Là, la perche est un peu grosse: utiliser un compilo notoirement
buggé
non mais faire une release avec ce compilo aussi, faut oser hein...
je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier
ne soit pas encore vraiment stabilisé...
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
Comme il est hors de question d'installer un programme qui ne compile pas
proprement, cette "aide" n'a aucun intérêt pour moi.
c'est justement ce qui provoque des "bug" ne pas avoir installer les
fichiers avant compilation comment veux tu que Gcc trouves les fichier et
lib si tu les as pas mis la ou cela doit etre et comme cela doit etre
On Tue, 06 Sep 2005 23:15:13 +0200, l'indien wrote:
sur une très vieille red-hat: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) Là, la perche est un peu grosse: utiliser un compilo notoirement
buggé
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier ne soit pas encore vraiment stabilisé...
pour info voici la procedure d'install pour openqm et une aide minimale
http://openqm.org/tiki-index.php?page=Help
Comme il est hors de question d'installer un programme qui ne compile pas proprement, cette "aide" n'a aucun intérêt pour moi.
c'est justement ce qui provoque des "bug" ne pas avoir installer les fichiers avant compilation comment veux tu que Gcc trouves les fichier et lib si tu les as pas mis la ou cela doit etre et comme cela doit etre
Stephane TOUGARD
helios wrote:
Comme il est hors de question d'installer un programme qui ne compile pas proprement, cette "aide" n'a aucun intérêt pour moi. c'est justement ce qui provoque des "bug" ne pas avoir installer les
fichiers avant compilation comment veux tu que Gcc trouves les fichier et lib si tu les as pas mis la ou cela doit etre et comme cela doit etre
Ah ben oui, forcement, comment veux tu compiler openqm si tu le downloades pas avant ? hein ?
Dis donc, ca c'est de l'expertise.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
helios wrote:
Comme il est hors de question d'installer un programme qui ne compile pas
proprement, cette "aide" n'a aucun intérêt pour moi.
c'est justement ce qui provoque des "bug" ne pas avoir installer les
fichiers avant compilation comment veux tu que Gcc trouves les fichier et
lib si tu les as pas mis la ou cela doit etre et comme cela doit etre
Ah ben oui, forcement, comment veux tu compiler openqm si tu le
downloades pas avant ? hein ?
Dis donc, ca c'est de l'expertise.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
Comme il est hors de question d'installer un programme qui ne compile pas proprement, cette "aide" n'a aucun intérêt pour moi. c'est justement ce qui provoque des "bug" ne pas avoir installer les
fichiers avant compilation comment veux tu que Gcc trouves les fichier et lib si tu les as pas mis la ou cela doit etre et comme cela doit etre
Ah ben oui, forcement, comment veux tu compiler openqm si tu le downloades pas avant ? hein ?
Dis donc, ca c'est de l'expertise.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
Vincent Bernat
OoO La nuit ayant déjà recouvert d'encre ce jour du mercredi 07 septembre 2005, vers 23:42, l'indien disait:
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier ne soit pas encore vraiment stabilisé...
Debian aussi. -- # Okay, what on Earth is this one supposed to be used for? 2.4.0 linux/drivers/char/cp437.uni
OoO La nuit ayant déjà recouvert d'encre ce jour du mercredi 07
septembre 2005, vers 23:42, l'indien <l_indien_no_more_spams@magic.fr>
disait:
non mais faire une release avec ce compilo aussi, faut oser hein...
je trouve que sur ce coup, ils n'ont pas assuré chez RH.
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier
ne soit pas encore vraiment stabilisé...
Debian aussi.
--
# Okay, what on Earth is this one supposed to be used for?
2.4.0 linux/drivers/char/cp437.uni
Oui. Et je crois qu'ils ont recommencé avec gcc 4, malgré que ce dernier ne soit pas encore vraiment stabilisé...
A non, gcc-4.0 (pure version fsf) est très bien : il refuse, pour de bonnes raisons, de compiler openqm (version du 2005-08-26) :
[...] gcc-4.0 -c -g -D_LARGEFILE64_SOURCE -DINTERNAL -DOPENQM -DLOAD_PCODE -I ./ -I ../BP.OUT/ -c -o op_ccall.o op_ccall.c op_ccall.c: In function 'ccall_c': op_ccall.c:81: error: invalid lvalue in increment op_ccall.c:85: error: invalid lvalue in assignment op_ccall.c:91: error: invalid lvalue in assignment op_ccall.c:92: error: invalid lvalue in increment op_ccall.c:97: error: invalid lvalue in increment op_ccall.c:101: error: invalid lvalue in increment op_ccall.c:108: error: invalid lvalue in increment op_ccall.c:443: error: invalid lvalue in increment op_ccall.c:448: error: invalid lvalue in increment op_ccall.c:456: error: invalid lvalue in increment op_ccall.c: In function 'op_ccall': op_ccall.c:504: warning: pointer targets in assignment differ in signedness op_ccall.c:520: warning: pointer targets in assignment differ in signedness make: *** [op_ccall.o] Error 1
-- Richard
Yannick Jestin
Vincent Bernat contribuat:
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH. [...]
Debian aussi.
Woody, la dernière release de debian est en 3.3.5, non ?
Ceci dit, un compilo peut être buggy à plein d'étages, et quand même pondre de beaux rapports d'erreurs. Il semble que celui-là collait davantage uax normes ISO C99 et C++98, d'après [1]
Mais cette version spécifique RH a un joli bug [2] sur le traitement d'une erreur rigolote: return (!flags & 0x80) ? 1 : 0;
non mais faire une release avec ce compilo aussi, faut oser hein...
je trouve que sur ce coup, ils n'ont pas assuré chez RH.
[...]
Debian aussi.
Woody, la dernière release de debian est en 3.3.5, non ?
Ceci dit, un compilo peut être buggy à plein d'étages, et quand même pondre de
beaux rapports d'erreurs. Il semble que celui-là collait davantage uax
normes ISO C99 et C++98, d'après [1]
Mais cette version spécifique RH a un joli bug [2] sur le traitement d'une
erreur rigolote: return (!flags & 0x80) ? 1 : 0;
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH. [...]
Debian aussi.
Woody, la dernière release de debian est en 3.3.5, non ?
Ceci dit, un compilo peut être buggy à plein d'étages, et quand même pondre de beaux rapports d'erreurs. Il semble que celui-là collait davantage uax normes ISO C99 et C++98, d'après [1]
Mais cette version spécifique RH a un joli bug [2] sur le traitement d'une erreur rigolote: return (!flags & 0x80) ? 1 : 0;
On Thu, 08 Sep 2005 11:33:52 +0000, Yannick Jestin wrote:
Vincent Bernat contribuat:
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH. [...]
Debian aussi.
Woody, la dernière release de debian est en 3.3.5, non ?
Ceci dit, un compilo peut être buggy à plein d'étages, et quand même pondre de beaux rapports d'erreurs. Il semble que celui-là collait davantage uax normes ISO C99 et C++98, d'après [1]
C'est vrai. Mais c'est aussi vrai qu'il est très dur de stabiliser un compilo, surtout pour ce qui concerne les bugs les plus subtils et les moins fréquents. Il y a 2 types de bugs qui reviennent souvent avec gcc 4: - les bugs d'optimisations. Ce ne sont pas des bugs majeurs, mais si le code produit est moins efficace que celui produit par gcc 3, il est interressant de garder ce dernier pour la production - les bugs d'allocations de registres: dans le meilleur des cas, ça se traduit par une erreur du type "unable to find a register...". Dans le pire des cas, le code ne marche pas ou erratiquement.
Mais cette version spécifique RH a un joli bug [2] sur le traitement d'une erreur rigolote: return (!flags & 0x80) ? 1 : 0;
Ce qui est une construction de base...
On ne peut pas blamer les développeurs. C'est du code tellement complexe... Il faut rappeler qu'il a fallu une bonne année avant que gcc 3 ne soit fiable sur x86 et un peu plus sur PowerPC et ça me semble assez normal.
On Thu, 08 Sep 2005 11:33:52 +0000, Yannick Jestin wrote:
Vincent Bernat contribuat:
non mais faire une release avec ce compilo aussi, faut oser hein...
je trouve que sur ce coup, ils n'ont pas assuré chez RH.
[...]
Debian aussi.
Woody, la dernière release de debian est en 3.3.5, non ?
Ceci dit, un compilo peut être buggy à plein d'étages, et quand même pondre de
beaux rapports d'erreurs. Il semble que celui-là collait davantage uax
normes ISO C99 et C++98, d'après [1]
C'est vrai.
Mais c'est aussi vrai qu'il est très dur de stabiliser un compilo,
surtout pour ce qui concerne les bugs les plus subtils et les moins
fréquents.
Il y a 2 types de bugs qui reviennent souvent avec gcc 4:
- les bugs d'optimisations. Ce ne sont pas des bugs majeurs, mais si le
code produit est moins efficace que celui produit par gcc 3, il est
interressant de garder ce dernier pour la production
- les bugs d'allocations de registres: dans le meilleur des cas, ça se
traduit par une erreur du type "unable to find a register...". Dans
le pire des cas, le code ne marche pas ou erratiquement.
Mais cette version spécifique RH a un joli bug [2] sur le traitement d'une
erreur rigolote: return (!flags & 0x80) ? 1 : 0;
Ce qui est une construction de base...
On ne peut pas blamer les développeurs. C'est du code tellement complexe...
Il faut rappeler qu'il a fallu une bonne année avant que gcc 3 ne soit
fiable sur x86 et un peu plus sur PowerPC et ça me semble assez normal.
On Thu, 08 Sep 2005 11:33:52 +0000, Yannick Jestin wrote:
Vincent Bernat contribuat:
non mais faire une release avec ce compilo aussi, faut oser hein... je trouve que sur ce coup, ils n'ont pas assuré chez RH. [...]
Debian aussi.
Woody, la dernière release de debian est en 3.3.5, non ?
Ceci dit, un compilo peut être buggy à plein d'étages, et quand même pondre de beaux rapports d'erreurs. Il semble que celui-là collait davantage uax normes ISO C99 et C++98, d'après [1]
C'est vrai. Mais c'est aussi vrai qu'il est très dur de stabiliser un compilo, surtout pour ce qui concerne les bugs les plus subtils et les moins fréquents. Il y a 2 types de bugs qui reviennent souvent avec gcc 4: - les bugs d'optimisations. Ce ne sont pas des bugs majeurs, mais si le code produit est moins efficace que celui produit par gcc 3, il est interressant de garder ce dernier pour la production - les bugs d'allocations de registres: dans le meilleur des cas, ça se traduit par une erreur du type "unable to find a register...". Dans le pire des cas, le code ne marche pas ou erratiquement.
Mais cette version spécifique RH a un joli bug [2] sur le traitement d'une erreur rigolote: return (!flags & 0x80) ? 1 : 0;
Ce qui est une construction de base...
On ne peut pas blamer les développeurs. C'est du code tellement complexe... Il faut rappeler qu'il a fallu une bonne année avant que gcc 3 ne soit fiable sur x86 et un peu plus sur PowerPC et ça me semble assez normal.