J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
J'ai fait un répertoire objdir à coté du répertoire des sources depuis
lequel je lance
configure --prefix=/usr/local/gcc-3.3.2 --enable-languages=c,c++,java
make bootstrap
et c'est là que je ne comprend plus
J'obtiens des erreurs de compil qui sont à chaque fois différentes
qq fois Assembler message : instruction inconnue
qq fois il plante sur la comparaison des stage 2 et 3
Comment expliquer le phénomène mais surtout comment compiler gcc jusqu'au
bout
PS : j'ai bien sûr vérifié que tous les prérequis étaient bons
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
OK , il faut pas oublier de le patcher avec les patches pour Linux . A moins que je confonde avec la GlibC ... mais bon .
J'obtiens des erreurs de compil qui sont à chaque fois différentes qq fois Assembler message : instruction inconnue qq fois il plante sur la comparaison des stage 2 et 3
Quand moi j'ai eu un tel souci c'etait ma carte mere qui partait en vrille . Ca peut tout aussi bien etre ta RAM .
Comment expliquer le phénomène mais surtout comment compiler gcc jusqu'au bout
Verifier avec du bon matos . sur et verifié .
PS : j'ai bien sûr vérifié que tous les prérequis étaient bons
Non , je pense que pour le matos , t'as supposé qu'il etait bon .
Merci de vos idées ou conseils
de rien :-)
tout compte fait c'est pour la glibc : http://linux-sxs.org/upgrading/glibc.html -- http://mrakotom.free.fr
Zeugma wrote:
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
OK , il faut pas oublier de le patcher avec les patches pour Linux .
A moins que je confonde avec la GlibC ... mais bon .
J'obtiens des erreurs de compil qui sont à chaque fois différentes
qq fois Assembler message : instruction inconnue
qq fois il plante sur la comparaison des stage 2 et 3
Quand moi j'ai eu un tel souci c'etait ma carte mere qui partait en vrille .
Ca peut tout aussi bien etre ta RAM .
Comment expliquer le phénomène mais surtout comment compiler gcc jusqu'au
bout
Verifier avec du bon matos . sur et verifié .
PS : j'ai bien sûr vérifié que tous les prérequis étaient bons
Non , je pense que pour le matos , t'as supposé qu'il etait bon .
Merci de vos idées ou conseils
de rien :-)
tout compte fait c'est pour la glibc :
http://linux-sxs.org/upgrading/glibc.html
--
http://mrakotom.free.fr
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
OK , il faut pas oublier de le patcher avec les patches pour Linux . A moins que je confonde avec la GlibC ... mais bon .
J'obtiens des erreurs de compil qui sont à chaque fois différentes qq fois Assembler message : instruction inconnue qq fois il plante sur la comparaison des stage 2 et 3
Quand moi j'ai eu un tel souci c'etait ma carte mere qui partait en vrille . Ca peut tout aussi bien etre ta RAM .
Comment expliquer le phénomène mais surtout comment compiler gcc jusqu'au bout
Verifier avec du bon matos . sur et verifié .
PS : j'ai bien sûr vérifié que tous les prérequis étaient bons
Non , je pense que pour le matos , t'as supposé qu'il etait bon .
Merci de vos idées ou conseils
de rien :-)
tout compte fait c'est pour la glibc : http://linux-sxs.org/upgrading/glibc.html -- http://mrakotom.free.fr
ecstasy
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
J'ai fait un répertoire objdir à coté du répertoire des sources depuis lequel je lance configure --prefix=/usr/local/gcc-3.3.2 --enable-languages=c,c++,java make bootstrap
ça veut dire quoi un répertoire "à côté" ?
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
J'ai fait un répertoire objdir à coté du répertoire des sources depuis
lequel je lance
configure --prefix=/usr/local/gcc-3.3.2 --enable-languages=c,c++,java
make bootstrap
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
J'ai fait un répertoire objdir à coté du répertoire des sources depuis lequel je lance configure --prefix=/usr/local/gcc-3.3.2 --enable-languages=c,c++,java make bootstrap
ça veut dire quoi un répertoire "à côté" ?
ecstasy
"Rakotomandimby" a écrit :
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
OK , il faut pas oublier de le patcher avec les patches pour Linux . A moins que je confonde avec la GlibC ... mais bon .
GlibC.
J'obtiens des erreurs de compil qui sont à chaque fois différentes qq fois Assembler message : instruction inconnue qq fois il plante sur la comparaison des stage 2 et 3
Quand moi j'ai eu un tel souci c'etait ma carte mere qui partait en vrille .
Ca peut tout aussi bien etre ta RAM .
Comment expliquer le phénomène mais surtout comment compiler gcc jusqu'au
bout
Verifier avec du bon matos . sur et verifié .
Ça peut venir du matos mais dans ce cas, mais la compilation de gcc n'est pas toujours évidente. Surtout avec des distros qui bidouillent leur version de gcc.
"Rakotomandimby" <mrakotom@free.fr> a écrit :
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
OK , il faut pas oublier de le patcher avec les patches pour Linux .
A moins que je confonde avec la GlibC ... mais bon .
GlibC.
J'obtiens des erreurs de compil qui sont à chaque fois différentes
qq fois Assembler message : instruction inconnue
qq fois il plante sur la comparaison des stage 2 et 3
Quand moi j'ai eu un tel souci c'etait ma carte mere qui partait en vrille
.
Ca peut tout aussi bien etre ta RAM .
Comment expliquer le phénomène mais surtout comment compiler gcc
jusqu'au
bout
Verifier avec du bon matos . sur et verifié .
Ça peut venir du matos mais dans ce cas, mais la compilation de gcc n'est
pas toujours évidente. Surtout avec des distros qui bidouillent leur version
de gcc.
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
OK , il faut pas oublier de le patcher avec les patches pour Linux . A moins que je confonde avec la GlibC ... mais bon .
GlibC.
J'obtiens des erreurs de compil qui sont à chaque fois différentes qq fois Assembler message : instruction inconnue qq fois il plante sur la comparaison des stage 2 et 3
Quand moi j'ai eu un tel souci c'etait ma carte mere qui partait en vrille .
Ca peut tout aussi bien etre ta RAM .
Comment expliquer le phénomène mais surtout comment compiler gcc jusqu'au
bout
Verifier avec du bon matos . sur et verifié .
Ça peut venir du matos mais dans ce cas, mais la compilation de gcc n'est pas toujours évidente. Surtout avec des distros qui bidouillent leur version de gcc.
SaMmMy !!!
tu créés un répertoire "temproraire", genre : # cd gcc-3.3.2 # mkdir compil # cd compil # ./configure --bla-bla-bla
comme ça, tes fichiers de compilation n'altèrent pas et n'encombrent pas ton répertoire de sources.
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
J'ai fait un répertoire objdir à coté du répertoire des sources depuis lequel je lance configure --prefix=/usr/local/gcc-3.3.2 --enable-languages=c,c++,java make bootstrap
ça veut dire quoi un répertoire "à côté" ?
tu créés un répertoire "temproraire", genre :
# cd gcc-3.3.2
# mkdir compil
# cd compil
# ./configure --bla-bla-bla
comme ça, tes fichiers de compilation n'altèrent pas et n'encombrent pas ton
répertoire de sources.
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
J'ai fait un répertoire objdir à coté du répertoire des sources depuis
lequel je lance
configure --prefix=/usr/local/gcc-3.3.2 --enable-languages=c,c++,java
make bootstrap
tu créés un répertoire "temproraire", genre : # cd gcc-3.3.2 # mkdir compil # cd compil # ./configure --bla-bla-bla
comme ça, tes fichiers de compilation n'altèrent pas et n'encombrent pas ton répertoire de sources.
Bonjour,
J'essaye de compiler GCC-3.3.2 sur ma Mandrake 9.1
J'ai fait un répertoire objdir à coté du répertoire des sources depuis lequel je lance configure --prefix=/usr/local/gcc-3.3.2 --enable-languages=c,c++,java make bootstrap
ça veut dire quoi un répertoire "à côté" ?
ecstasy
"SaMmMy !!!" a écrit dans le message de news:
tu créés un répertoire "temproraire", genre : # cd gcc-3.3.2 # mkdir compil # cd compil # ./configure --bla-bla-bla
comme ça, tes fichiers de compilation n'altèrent pas et n'encombrent pas ton
répertoire de sources.
Merci de me le préciser. Sauf qu'ayant déjà compilé gcc avec cette tactique là, j'ai eu pleins de problèmes. Après consultation de la doc de gcc, j'ai vu qu'il est FORTEMENT recommandé de ne pas créer le dossier objdir dans la même arborescence que le répertoire où gcc a été décompressé. Ça peut paraître con comme recommandation, mais en la respectant j'ai réussi - par miracle - à le compiler.
"SaMmMy !!!" <powerofcombi@ifrance.com> a écrit dans le message de
news:3FFA6B55.90A5FF4C@ifrance.com...
tu créés un répertoire "temproraire", genre :
# cd gcc-3.3.2
# mkdir compil
# cd compil
# ./configure --bla-bla-bla
comme ça, tes fichiers de compilation n'altèrent pas et n'encombrent pas
ton
répertoire de sources.
Merci de me le préciser. Sauf qu'ayant déjà compilé gcc avec cette tactique
là, j'ai eu pleins de problèmes. Après consultation de la doc de gcc, j'ai
vu qu'il est FORTEMENT recommandé de ne pas créer le dossier objdir dans la
même arborescence que le répertoire où gcc a été décompressé. Ça peut
paraître con comme recommandation, mais en la respectant j'ai réussi - par
miracle - à le compiler.
tu créés un répertoire "temproraire", genre : # cd gcc-3.3.2 # mkdir compil # cd compil # ./configure --bla-bla-bla
comme ça, tes fichiers de compilation n'altèrent pas et n'encombrent pas ton
répertoire de sources.
Merci de me le préciser. Sauf qu'ayant déjà compilé gcc avec cette tactique là, j'ai eu pleins de problèmes. Après consultation de la doc de gcc, j'ai vu qu'il est FORTEMENT recommandé de ne pas créer le dossier objdir dans la même arborescence que le répertoire où gcc a été décompressé. Ça peut paraître con comme recommandation, mais en la respectant j'ai réussi - par miracle - à le compiler.
Zeugma
"ecstasy" écrit dans news:btdqvk$1kf3$:
Aprs consultation de la doc de gcc, j'ai vu qu'il est FORTEMENT recommand de ne pas crer le dossier objdir dans la mme arborescence que le rpertoire o gcc a t dcompress. a peut paratre con comme recommandation, mais en la respectant j'ai russi - par miracle - le compiler.
J'ai aussi respecté cette recommendation : le répertoire de compil n'est ni pére ni fils du répertoire des sources.
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le coté déterministe d'une compilation ?
"ecstasy" <pasde@pub.com> écrit dans
news:btdqvk$1kf3$1@biggoron.nerim.net:
Aprs consultation de la doc de gcc, j'ai
vu qu'il est FORTEMENT recommand de ne pas crer le dossier objdir
dans la mme arborescence que le rpertoire o gcc a t dcompress.
a peut paratre con comme recommandation, mais en la respectant j'ai
russi - par miracle - le compiler.
J'ai aussi respecté cette recommendation : le répertoire de compil n'est ni
pére ni fils du répertoire des sources.
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le
coté déterministe d'une compilation ?
Aprs consultation de la doc de gcc, j'ai vu qu'il est FORTEMENT recommand de ne pas crer le dossier objdir dans la mme arborescence que le rpertoire o gcc a t dcompress. a peut paratre con comme recommandation, mais en la respectant j'ai russi - par miracle - le compiler.
J'ai aussi respecté cette recommendation : le répertoire de compil n'est ni pére ni fils du répertoire des sources.
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le coté déterministe d'une compilation ?
Zeugma
Rakotomandimby écrit dans news:btdmck$l2u$ reader3.wanadoo.fr:
Verifier avec du bon matos . sur et verifi .
PS : j'ai bien sr vrifi que tous les prrequis taient bons
Non , je pense que pour le matos , t'as suppos qu'il etait bon .
Quelle procédure de vérification du matériel proposes tu ? Sachant tout de même que le micro fonctionne sous Linux depuis un bout de temps sans problème... mais tout peut arriver !
Rakotomandimby <mrakotom@free.fr> écrit dans news:btdmck$l2u$1@news-
reader3.wanadoo.fr:
Verifier avec du bon matos . sur et verifi .
PS : j'ai bien sr vrifi que tous les prrequis taient bons
Non , je pense que pour le matos , t'as suppos qu'il etait bon .
Quelle procédure de vérification du matériel proposes tu ?
Sachant tout de même que le micro fonctionne sous Linux depuis un bout de
temps sans problème... mais tout peut arriver !
Rakotomandimby écrit dans news:btdmck$l2u$ reader3.wanadoo.fr:
Verifier avec du bon matos . sur et verifi .
PS : j'ai bien sr vrifi que tous les prrequis taient bons
Non , je pense que pour le matos , t'as suppos qu'il etait bon .
Quelle procédure de vérification du matériel proposes tu ? Sachant tout de même que le micro fonctionne sous Linux depuis un bout de temps sans problème... mais tout peut arriver !
ecstasy
"Zeugma" a écrit dans le message de news:
Rakotomandimby écrit dans news:btdmck$l2u$ reader3.wanadoo.fr:
Verifier avec du bon matos . sur et verifi .
PS : j'ai bien sr vrifi que tous les prrequis taient bons
Non , je pense que pour le matos , t'as suppos qu'il etait bon .
Quelle procédure de vérification du matériel proposes tu ? Sachant tout de même que le micro fonctionne sous Linux depuis un bout de temps sans problème... mais tout peut arriver !
première étape : Si au boot de l'ordinateur, tu ne vois pas la RAM défiler pendant un bref instant ( dépendamment de ton CPU bien sûr ) faire ce qui suit : Entrer dans le bios, désactiver l'option "Quick Boot" ou un truc du genre et redémarrer la machine. ( en boot normal, le BIOS vérifie tous les composants, y compris la RAM. Un Quick Boot, est un boot où certaines vérifications ne sont pas faites, dont la RAM ). Si c'est une RAM défectueuse, il y aura des Bips d'erreur et un message du bios.
à ce niveau là, si la RAM est défectueuse, rien à faire sinon la ramener au magasin ou en acheter une autre. ( si tu es sur Paris, les chinois du 12è refourguent souvent des barettes douteuses ; quand j'achète chez eux, je vérifie tout de suite la Ram en rentrant ).
Si le test bios n'indique aucune erreur, cela ne signifie pas pour autant que la Ram est défectueuse. Passer à l'étape deux :
étape deux : télécharger ce logiciel qui fait référence : http://www.memtest86.com/ lire la doc qui va bien avec et tester la mémoire avec.
Si c'est une erreur de Ram, rien à faire il faut la changer.
"Zeugma" <ann.onym@dummy.net> a écrit dans le message de
news:Xns94688C5EA9D62zeugmaposeidonfreefr@213.228.0.136...
Rakotomandimby <mrakotom@free.fr> écrit dans news:btdmck$l2u$1@news-
reader3.wanadoo.fr:
Verifier avec du bon matos . sur et verifi .
PS : j'ai bien sr vrifi que tous les prrequis taient bons
Non , je pense que pour le matos , t'as suppos qu'il etait bon .
Quelle procédure de vérification du matériel proposes tu ?
Sachant tout de même que le micro fonctionne sous Linux depuis un bout de
temps sans problème... mais tout peut arriver !
première étape :
Si au boot de l'ordinateur, tu ne vois pas la RAM défiler pendant un bref
instant ( dépendamment de ton CPU bien sûr ) faire ce qui suit :
Entrer dans le bios, désactiver l'option "Quick Boot" ou un truc du genre et
redémarrer la machine. ( en boot normal, le BIOS vérifie tous les
composants, y compris la RAM. Un Quick Boot, est un boot où certaines
vérifications ne sont pas faites, dont la RAM ).
Si c'est une RAM défectueuse, il y aura des Bips d'erreur et un message du
bios.
à ce niveau là, si la RAM est défectueuse, rien à faire sinon la ramener au
magasin ou en acheter une autre. ( si tu es sur Paris, les chinois du 12è
refourguent souvent des barettes douteuses ; quand j'achète chez eux, je
vérifie tout de suite la Ram en rentrant ).
Si le test bios n'indique aucune erreur, cela ne signifie pas pour autant
que la Ram est défectueuse. Passer à l'étape deux :
étape deux :
télécharger ce logiciel qui fait référence :
http://www.memtest86.com/
lire la doc qui va bien avec et tester la mémoire avec.
Si c'est une erreur de Ram, rien à faire il faut la changer.
Rakotomandimby écrit dans news:btdmck$l2u$ reader3.wanadoo.fr:
Verifier avec du bon matos . sur et verifi .
PS : j'ai bien sr vrifi que tous les prrequis taient bons
Non , je pense que pour le matos , t'as suppos qu'il etait bon .
Quelle procédure de vérification du matériel proposes tu ? Sachant tout de même que le micro fonctionne sous Linux depuis un bout de temps sans problème... mais tout peut arriver !
première étape : Si au boot de l'ordinateur, tu ne vois pas la RAM défiler pendant un bref instant ( dépendamment de ton CPU bien sûr ) faire ce qui suit : Entrer dans le bios, désactiver l'option "Quick Boot" ou un truc du genre et redémarrer la machine. ( en boot normal, le BIOS vérifie tous les composants, y compris la RAM. Un Quick Boot, est un boot où certaines vérifications ne sont pas faites, dont la RAM ). Si c'est une RAM défectueuse, il y aura des Bips d'erreur et un message du bios.
à ce niveau là, si la RAM est défectueuse, rien à faire sinon la ramener au magasin ou en acheter une autre. ( si tu es sur Paris, les chinois du 12è refourguent souvent des barettes douteuses ; quand j'achète chez eux, je vérifie tout de suite la Ram en rentrant ).
Si le test bios n'indique aucune erreur, cela ne signifie pas pour autant que la Ram est défectueuse. Passer à l'étape deux :
étape deux : télécharger ce logiciel qui fait référence : http://www.memtest86.com/ lire la doc qui va bien avec et tester la mémoire avec.
Si c'est une erreur de Ram, rien à faire il faut la changer.
ecstasy
"Zeugma" a écrit dans le message de news:
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le coté déterministe d'une compilation ?
Pas du tout. C'était juste un soupçon de sarcasme dû à un réveil du mauvais pied ( je m'en excuse encore ). Ceci dit pour ton problème, on lit souvent que gcc 3.2 ( qui est livré avec Mandrake 9.1 si mes souvenirs sont bons ) est connu pour produire du code buggué. Il est possible que ce soit lui la cause de ces erreurs de compil mais ça serait étonnant quand même vu les erreurs que tu as.
Petite info utile : si tu comptes utiliser le nouveau compilateur compilé pour compiler, je te conseille de faire un
make LIBCFLAG=-O2 LIBCXXFLAG=-O2 bootstrap
( ajouter les options d'optimisations qui vont bien avec le -O2 )
car par défaut les libs seront compilées avec des flags de debugage. Il ne génèrera donc du code environ 3X plus lent.( j'ai mis des semaines à trouver d'où venait ce manque de perf lors de mes premières compils de gcc.. )
"Zeugma" <ann.onym@dummy.net> a écrit dans le message de
news:Xns94688B5EA4326zeugmaposeidonfreefr@213.228.0.136...
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le
coté déterministe d'une compilation ?
Pas du tout. C'était juste un soupçon de sarcasme dû à un réveil du mauvais
pied ( je m'en excuse encore ).
Ceci dit pour ton problème, on lit souvent que gcc 3.2 ( qui est livré avec
Mandrake 9.1 si mes souvenirs sont bons ) est connu pour produire du code
buggué. Il est possible que ce soit lui la cause de ces erreurs de compil
mais ça serait étonnant quand même vu les erreurs que tu as.
Petite info utile : si tu comptes utiliser le nouveau compilateur compilé
pour compiler, je te conseille de faire un
make LIBCFLAG=-O2 LIBCXXFLAG=-O2 bootstrap
( ajouter les options d'optimisations qui vont bien avec le -O2 )
car par défaut les libs seront compilées avec des flags de debugage. Il ne
génèrera donc du code environ 3X plus lent.( j'ai mis des semaines à trouver
d'où venait ce manque de perf lors de mes premières compils de gcc.. )
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le coté déterministe d'une compilation ?
Pas du tout. C'était juste un soupçon de sarcasme dû à un réveil du mauvais pied ( je m'en excuse encore ). Ceci dit pour ton problème, on lit souvent que gcc 3.2 ( qui est livré avec Mandrake 9.1 si mes souvenirs sont bons ) est connu pour produire du code buggué. Il est possible que ce soit lui la cause de ces erreurs de compil mais ça serait étonnant quand même vu les erreurs que tu as.
Petite info utile : si tu comptes utiliser le nouveau compilateur compilé pour compiler, je te conseille de faire un
make LIBCFLAG=-O2 LIBCXXFLAG=-O2 bootstrap
( ajouter les options d'optimisations qui vont bien avec le -O2 )
car par défaut les libs seront compilées avec des flags de debugage. Il ne génèrera donc du code environ 3X plus lent.( j'ai mis des semaines à trouver d'où venait ce manque de perf lors de mes premières compils de gcc.. )
J. Mayer
On Tue, 06 Jan 2004 14:49:10 +0100, ecstasy wrote:
"Zeugma" a écrit dans le message de news:
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le coté déterministe d'une compilation ?
Pas du tout. C'était juste un soupçon de sarcasme dû à un réveil du mauvais pied ( je m'en excuse encore ). Ceci dit pour ton problème, on lit souvent que gcc 3.2 ( qui est livré avec Mandrake 9.1 si mes souvenirs sont bons ) est connu pour produire du code buggué. Il est possible que ce soit lui la cause de ces erreurs de compil mais ça serait étonnant quand même vu les erreurs que tu as.
Petite info utile : si tu comptes utiliser le nouveau compilateur compilé pour compiler, je te conseille de faire un
make LIBCFLAG=-O2 LIBCXXFLAG=-O2 bootstrap
( ajouter les options d'optimisations qui vont bien avec le -O2 )
car par défaut les libs seront compilées avec des flags de debugage. Il ne génèrera donc du code environ 3X plus lent.( j'ai mis des semaines à trouver d'où venait ce manque de perf lors de mes premières compils de gcc.. )
Le -O2 ne génère pas de code de débug, ça désactive les optimisations, nuance... Et le bootstrap est indispensable: ça demande au compilateur de se recompiler lui-même et de vérifier qu'il aboutit au même résultat que la première compilation. Il n'y a que pour compiler un cross-compilateur qu'il faut ne pas le mettre. Faire un simple "make" pour recompiler gcc, c'est prendre un très gros risque... Le make bootstrap ne detecte pas tous les bugs mais permet de s'assurer que le compilateur sait compiler du C standard, ce qui n'est déjà pas si mal. Par contre, ça ne dit pas si il saura compiler du code un peu spécial, genre un kernel (à cause de problèmes d'aliasing, d'assembleur inline, ...).
On Tue, 06 Jan 2004 14:49:10 +0100, ecstasy wrote:
"Zeugma" <ann.onym@dummy.net> a écrit dans le message de
news:Xns94688B5EA4326zeugmaposeidonfreefr@213.228.0.136...
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le
coté déterministe d'une compilation ?
Pas du tout. C'était juste un soupçon de sarcasme dû à un réveil du mauvais
pied ( je m'en excuse encore ).
Ceci dit pour ton problème, on lit souvent que gcc 3.2 ( qui est livré avec
Mandrake 9.1 si mes souvenirs sont bons ) est connu pour produire du code
buggué. Il est possible que ce soit lui la cause de ces erreurs de compil
mais ça serait étonnant quand même vu les erreurs que tu as.
Petite info utile : si tu comptes utiliser le nouveau compilateur compilé
pour compiler, je te conseille de faire un
make LIBCFLAG=-O2 LIBCXXFLAG=-O2 bootstrap
( ajouter les options d'optimisations qui vont bien avec le -O2 )
car par défaut les libs seront compilées avec des flags de debugage. Il ne
génèrera donc du code environ 3X plus lent.( j'ai mis des semaines à trouver
d'où venait ce manque de perf lors de mes premières compils de gcc.. )
Le -O2 ne génère pas de code de débug, ça désactive les optimisations,
nuance...
Et le bootstrap est indispensable: ça demande au compilateur de
se recompiler lui-même et de vérifier qu'il aboutit au même résultat
que la première compilation. Il n'y a que pour compiler un
cross-compilateur qu'il faut ne pas le mettre.
Faire un simple "make" pour recompiler gcc, c'est prendre un très
gros risque...
Le make bootstrap ne detecte pas tous les bugs mais permet de
s'assurer que le compilateur sait compiler du C standard, ce qui
n'est déjà pas si mal. Par contre, ça ne dit pas si il saura compiler
du code un peu spécial, genre un kernel (à cause de problèmes d'aliasing,
d'assembleur inline, ...).
On Tue, 06 Jan 2004 14:49:10 +0100, ecstasy wrote:
"Zeugma" a écrit dans le message de news:
Est-ce que la mention "par miracle" signifie que tu as des doutes sur le coté déterministe d'une compilation ?
Pas du tout. C'était juste un soupçon de sarcasme dû à un réveil du mauvais pied ( je m'en excuse encore ). Ceci dit pour ton problème, on lit souvent que gcc 3.2 ( qui est livré avec Mandrake 9.1 si mes souvenirs sont bons ) est connu pour produire du code buggué. Il est possible que ce soit lui la cause de ces erreurs de compil mais ça serait étonnant quand même vu les erreurs que tu as.
Petite info utile : si tu comptes utiliser le nouveau compilateur compilé pour compiler, je te conseille de faire un
make LIBCFLAG=-O2 LIBCXXFLAG=-O2 bootstrap
( ajouter les options d'optimisations qui vont bien avec le -O2 )
car par défaut les libs seront compilées avec des flags de debugage. Il ne génèrera donc du code environ 3X plus lent.( j'ai mis des semaines à trouver d'où venait ce manque de perf lors de mes premières compils de gcc.. )
Le -O2 ne génère pas de code de débug, ça désactive les optimisations, nuance... Et le bootstrap est indispensable: ça demande au compilateur de se recompiler lui-même et de vérifier qu'il aboutit au même résultat que la première compilation. Il n'y a que pour compiler un cross-compilateur qu'il faut ne pas le mettre. Faire un simple "make" pour recompiler gcc, c'est prendre un très gros risque... Le make bootstrap ne detecte pas tous les bugs mais permet de s'assurer que le compilateur sait compiler du C standard, ce qui n'est déjà pas si mal. Par contre, ça ne dit pas si il saura compiler du code un peu spécial, genre un kernel (à cause de problèmes d'aliasing, d'assembleur inline, ...).
