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
Ce qui est faux. Le code du "kernel" n'a pas de dépendance externe. Il réimplémente même (assez mal, mais bon...) des fonctions habituellement dans la libc... Les objets qui sont indiqués dans cette documentation sont justement ceux que l'on compile. Un objet ne peut pas dépendre de lui même, c'est une abération....
On Thu, 08 Sep 2005 07:22:23 +0200, helios wrote:
"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
Ce qui est faux. Le code du "kernel" n'a pas de dépendance externe.
Il réimplémente même (assez mal, mais bon...) des fonctions
habituellement dans la libc...
Les objets qui sont indiqués dans cette documentation sont justement ceux
que l'on compile. Un objet ne peut pas dépendre de lui même, c'est une
abération....
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
Ce qui est faux. Le code du "kernel" n'a pas de dépendance externe. Il réimplémente même (assez mal, mais bon...) des fonctions habituellement dans la libc... Les objets qui sont indiqués dans cette documentation sont justement ceux que l'on compile. Un objet ne peut pas dépendre de lui même, c'est une abération....
Benjamin FRANCOIS
Yannick Jestin s'est exprimé en ces termes:
Woody, la dernière release de debian est en 3.3.5, non ?
Non, c'est Sarge la dernière release de Debian.
-- Every time, god damn, I look at my seed, I see something I can't be, Beautiful and care free, that's how I used to be... Like some god damn fucking freak, I'm so pressured, I'm so worried, Something takes a hold of me, something I can't believe...
Yannick Jestin s'est exprimé en ces termes:
Woody, la dernière release de debian est en 3.3.5, non ?
Non, c'est Sarge la dernière release de Debian.
--
Every time, god damn, I look at my seed, I see something I can't be,
Beautiful and care free, that's how I used to be...
Like some god damn fucking freak, I'm so pressured, I'm so worried,
Something takes a hold of me, something I can't believe...
Woody, la dernière release de debian est en 3.3.5, non ?
Non, c'est Sarge la dernière release de Debian.
-- Every time, god damn, I look at my seed, I see something I can't be, Beautiful and care free, that's how I used to be... Like some god damn fucking freak, I'm so pressured, I'm so worried, Something takes a hold of me, something I can't believe...
Yannick Jestin
Benjamin m'a corrigé:
Non, c'est Sarge la dernière release de Debian.
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci Benjamin !
Lindien: Les bugs d'optimisation ou d'allocation de registre, c'est la partie finale, et on est loin des détections d'erreur liées à la conformité au langage depuis, huuuuuuh, au moins deux étages.
-- Y. (*) et à tous mes descendants jusqu'à la nième génération
Benjamin m'a corrigé:
Non, c'est Sarge la dernière release de Debian.
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci
Benjamin !
Lindien: Les bugs d'optimisation ou d'allocation de registre, c'est
la partie finale, et on est loin des détections d'erreur liées à la
conformité au langage depuis, huuuuuuh, au moins deux étages.
--
Y.
(*) et à tous mes descendants jusqu'à la nième génération
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci Benjamin !
Lindien: Les bugs d'optimisation ou d'allocation de registre, c'est la partie finale, et on est loin des détections d'erreur liées à la conformité au langage depuis, huuuuuuh, au moins deux étages.
-- Y. (*) et à tous mes descendants jusqu'à la nième génération
Benjamin FRANCOIS
Yannick Jestin s'est exprimé en ces termes:
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci Benjamin !
Exact. À noter que gcc-3.4 est également fourni.
-- <morganj> 0 is false and 1 is true, correct? <alec_eso> 1, morganj <morganj> bastard.
Yannick Jestin s'est exprimé en ces termes:
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci
Benjamin !
Exact. À noter que gcc-3.4 est également fourni.
--
<morganj> 0 is false and 1 is true, correct?
<alec_eso> 1, morganj
<morganj> bastard.
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci Benjamin !
Exact. À noter que gcc-3.4 est également fourni.
-- <morganj> 0 is false and 1 is true, correct? <alec_eso> 1, morganj <morganj> bastard.
Thierry Boudet
On 2005-09-06, l'indien 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)
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...
D'un autre coté, c'est juste pour que les gens se rendent compte des négligences de ces gens-là... Exemple: implicit declaration of function `negotiate_telnet_parameter' ben, moi, ça ne me rassure pas trop :)
On 2005-09-06, l'indien <l_indien_no_more_spams@magic.fr> 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)
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...
D'un autre coté, c'est juste pour que les gens se rendent compte
des négligences de ces gens-là... Exemple:
implicit declaration of function `negotiate_telnet_parameter'
ben, moi, ça ne me rassure pas trop :)
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é pour faire des tests, ce n'est pas forcément une très bonne idée...
D'un autre coté, c'est juste pour que les gens se rendent compte des négligences de ces gens-là... Exemple: implicit declaration of function `negotiate_telnet_parameter' ben, moi, ça ne me rassure pas trop :)
OoO Lors de la soirée naissante du jeudi 08 septembre 2005, vers 17:01, Yannick Jestin disait:
Non, c'est Sarge la dernière release de Debian.
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci Benjamin !
Dans unstable, c'est du gcc-4. -- panic("Unable to find empty mailbox for aha1542.n"); 2.2.16 /usr/src/linux/drivers/scsi/aha1542.c
l'indien
On Thu, 08 Sep 2005 15:01:26 +0000, Yannick Jestin wrote:
Benjamin m'a corrigé:
Non, c'est Sarge la dernière release de Debian.
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci Benjamin !
Lindien: Les bugs d'optimisation ou d'allocation de registre, c'est la partie finale, et on est loin des détections d'erreur liées à la conformité au langage depuis, huuuuuuh, au moins deux étages.
Oui, mais générer du code correct qui s'execute correctement sur le processeur cible est la première priorité. L'optimiser, ajouter des subtilité du langage sont des features interressantes mais ne servent à rien si la partie basique ne fonctionne pas: l'allocation des registres est à la base de tout. Un bug dans la gestion des dépendances et le compilo est bon à jeter: le code buggera à un endroit ou un autre. Alors que s'il oublie de détecter une erreur subtile du langage mais produit du code correct derrière, au moins tu as un programme qui a quand même de grandes chances de tourner.
On Thu, 08 Sep 2005 15:01:26 +0000, Yannick Jestin wrote:
Benjamin m'a corrigé:
Non, c'est Sarge la dernière release de Debian.
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci
Benjamin !
Lindien: Les bugs d'optimisation ou d'allocation de registre, c'est
la partie finale, et on est loin des détections d'erreur liées à la
conformité au langage depuis, huuuuuuh, au moins deux étages.
Oui, mais générer du code correct qui s'execute correctement sur le
processeur cible est la première priorité. L'optimiser, ajouter des
subtilité du langage sont des features interressantes mais ne servent à
rien si la partie basique ne fonctionne pas: l'allocation des registres
est à la base de tout. Un bug dans la gestion des dépendances et le
compilo est bon à jeter: le code buggera à un endroit ou un autre.
Alors que s'il oublie de détecter une erreur subtile du langage mais
produit du code correct derrière, au moins tu as un programme qui a quand
même de grandes chances de tourner.
On Thu, 08 Sep 2005 15:01:26 +0000, Yannick Jestin wrote:
Benjamin m'a corrigé:
Non, c'est Sarge la dernière release de Debian.
Voilà, tout à fait, honte à moi (*). Donc du gcc3.3.5, et pas du gcc4. Merci Benjamin !
Lindien: Les bugs d'optimisation ou d'allocation de registre, c'est la partie finale, et on est loin des détections d'erreur liées à la conformité au langage depuis, huuuuuuh, au moins deux étages.
Oui, mais générer du code correct qui s'execute correctement sur le processeur cible est la première priorité. L'optimiser, ajouter des subtilité du langage sont des features interressantes mais ne servent à rien si la partie basique ne fonctionne pas: l'allocation des registres est à la base de tout. Un bug dans la gestion des dépendances et le compilo est bon à jeter: le code buggera à un endroit ou un autre. Alors que s'il oublie de détecter une erreur subtile du langage mais produit du code correct derrière, au moins tu as un programme qui a quand même de grandes chances de tourner.
