Compilation de gcc 4.3.1 par Sun Studio 12 (Solaris)

Le
JKB
Bonjour à tous,

Petit problème du jour. Je dois bootstraper un gcc 4.3.1 à l'aide de
Sun Studio 12 sur ce genre de bête :

poincare:[/usr/local/src/gcc-build] > uname -a
SunOS poincare 5.10 Generic_127128-11 i86pc i386 i86pc
poincare:[/usr/local/src/gcc-build] >

Ce n'est pas la première fois que je compile gcc et j'ai une
certaine habitude Par contre, c'est la première fois que je le
compile depuis Sun Studio.

1/ Sun Studio est installé correctement puisqu'il m'a permis de
compiler tous les prérequis sans problèmes ;
2/ l'étape de configuration est passée sans souci ;
3/ la compilation plante sur :

cc -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3.1/gcc
-I../../gcc-4.3.1/gcc/. -I../../gcc-4.3.1/gcc/../include -I./../intl
-I../../gcc-4.3.1/gcc/../libcpp/include -I/usr/local/include
-I/usr/local/include -I../../gcc-4.3.1/gcc/../libdecnumber
-I../../gcc-4.3.1/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc-4.3.1/gcc/c-common.c -o c-common.o
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: short_fract_type_no
"../../gcc-4.3.1/gcc/c-common.c", line 2254: syntax error before or at: ||
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: unsigned_short_frac
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: unsigned_short_frac
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: short_fract_type_no
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: fract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: syntax error before or at:
||

La ligne en question est une macro qui ne me semble pas vraiment
tordue :

C_COMMON_FIXED_TYPES (, fract);

au détail près qu'un argument est nul et qu'il est utilisé dans la
macro comme suit :

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;

Est-ce une utilisation standard du préprocesseur ? Et si non,
comment contourner le truc ? J'avoue ne pas savoir ce que fait
'SAT ## NAME ## _type_node'

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
espie
Le #6918931
In article JKB
if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;

Est-ce une utilisation standard du préprocesseur ? Et si non,
comment contourner le truc ? J'avoue ne pas savoir ce que fait
'SAT ## NAME ## _type_node'...

Cordialement,

JKB


C'est du preprocesseur ANSI un peu tordu... Il doit y avoir un bug d'evaluation
dans ton SunStudio, ou alors c'est un bug dans gcc qui `passe' a travers le
preprocesseur et qui ne se repere pas ailleurs... les regles d'evaluations
sont passablement tordues, et je n'ais pas ma norme sous la main.

Ta meilleure chance, ca serait d'avoir un preprocesseur qui marche, et
de configurer ton build de gcc pour utiliser ton compilateur sunstudio
plus un preprocesseur un peu mieux.

- regarde voir dans ta doc sunstudio s'il n'y a pas des options obscures
de compatibilite.
- tu peux essayer un preproc "standard" comme ucpp, qui devrait compiler
sans probleme (http://pornin.nerim.net/ucpp/)
- tu peux aussi essayer de bootstrapper en passant par un GCC plus ancien.

JKB
Le #6918921
Le 11-06-2008, à propos de
Re: Compilation de gcc 4.3.1 par Sun Studio 12 (Solaris),
Marc Espie écrivait dans fr.comp.lang.c :
In article JKB
if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;

Est-ce une utilisation standard du préprocesseur ? Et si non,
comment contourner le truc ? J'avoue ne pas savoir ce que fait
'SAT ## NAME ## _type_node'...

Cordialement,

JKB


C'est du preprocesseur ANSI un peu tordu... Il doit y avoir un bug d'evaluation
dans ton SunStudio, ou alors c'est un bug dans gcc qui `passe' a travers le
preprocesseur et qui ne se repere pas ailleurs... les regles d'evaluations
sont passablement tordues, et je n'ais pas ma norme sous la main.

Ta meilleure chance, ca serait d'avoir un preprocesseur qui marche, et
de configurer ton build de gcc pour utiliser ton compilateur sunstudio
plus un preprocesseur un peu mieux.

- regarde voir dans ta doc sunstudio s'il n'y a pas des options obscures
de compatibilite.
- tu peux essayer un preproc "standard" comme ucpp, qui devrait compiler
sans probleme (http://pornin.nerim.net/ucpp/)


Site down. Y a-t-il un tarball ailleurs, je n'ai pas trouvé...

- tu peux aussi essayer de bootstrapper en passant par un GCC plus ancien.


Justement, j'aimerais assez éviter.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


espie
Le #6920151
In article JKB
- tu peux essayer un preproc "standard" comme ucpp, qui devrait compiler
sans probleme (http://pornin.nerim.net/ucpp/)


Site down. Y a-t-il un tarball ailleurs, je n'ai pas trouvé...

C'est dans les ports de la plupart des bsd, on a des miroirs de distfiles

un peu partout.

Par exemple, ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/ucpp-1.2.tar.gz


Antoine Leca
Le #6923581
En news:g2oed8$asm$, Marc Espie va escriure:
if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;
- tu peux essayer un preproc "standard" comme ucpp, qui devrait

compiler sans probleme


Cette construction ne plaît pas du tout à ucpp...

C> type paste.c
#define C_COMMON_FIXED_TYPES(SAT,NAME)
if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;
C_COMMON_FIXED_TYPES (, fract);

C> ucpp paste.c
paste.c: warning: line 7: operator '##' produced the invalid token ' fract'
paste.c: warning: line 7: operator '##' produced the invalid token ' u'
paste.c: warning: line 7: operator '##' produced the invalid token ' u'
paste.c: warning: line 7: operator '##' produced the invalid token ' fract'
#line 1 "paste.c"





if (type1 == fract_type_node || type1 == ufract_type_node) return unsignedp
? u
fract_type_node : fract_type_node; ;


espie
Le #6923571
In article Antoine Leca
En news:g2oed8$asm$, Marc Espie va escriure:
if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;
- tu peux essayer un preproc "standard" comme ucpp, qui devrait

compiler sans probleme


Cette construction ne plaît pas du tout à ucpp...

C> type paste.c
#define C_COMMON_FIXED_TYPES(SAT,NAME)
if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;
C_COMMON_FIXED_TYPES (, fract);

C> ucpp paste.c
paste.c: warning: line 7: operator '##' produced the invalid token ' fract'
paste.c: warning: line 7: operator '##' produced the invalid token ' u'
paste.c: warning: line 7: operator '##' produced the invalid token ' u'
paste.c: warning: line 7: operator '##' produced the invalid token ' fract'
#line 1 "paste.c"





if (type1 == fract_type_node || type1 == ufract_type_node) return unsignedp
? u
fract_type_node : fract_type_node; ;





Bon, ben c'est un gros bug dans gcc, alors... Au moins on est fixe. ;-)



Antoine Leca
Le #6923561
En news:, JKB va escriure:
1/ Sun Studio est installé correctement puisqu'il m'a permis de
compiler tous les prérequis sans problèmes ;
2/ l'étape de configuration est passée sans souci ;
3/ la compilation plante sur :


Quelle phase ? Je suppose la première (c'est-à-dire en utilisant les outils
natifs, "bootstrap"), mais bon...

C_COMMON_FIXED_TYPES (, fract);


D'après Google tu n'es pas le seul avec ce souci.
cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id3304
htpp://gcc.gnu.org/ml/gcc-bugs/2007-09/msg00258.html
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01137.html
Vu que le problème a (au moins) 9 mois et est correctement reporté pour
autant que je puisse voir, on dirait pas que les mainteneurs de GCC ont
l'intention de faire des efforts supplémentaires pour le corriger.
Surtout qu'il y a un correctif évident, utiliser une version plus ancienne
de GCC pour compiler la bête de course.

Maintenant, si tu trouves une correction à appliquer au source, peut-être
qu'ils le prendront...



au détail près qu'un argument est nul et qu'il est utilisé dans la
macro comme suit :



Je rajoute devant :

#define C_COMMON_FIXED_TYPES(SAT,NAME)

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;


Et il faut donc savoir évaluer
== SAT ## NAME ## _type_node
quand SAT est vide. Si le préprocessur est conforme C99 (donc sait manipuler
les arguments vides, concept de "placeholders" dans la norme), pas de souci
; par contre, s'il est conforme à la norme C90, le SAT compte pour du
beurre, et l'évaluation de
== ## NAME
donne ==NAME, qui n'est pas un élément lexical correct, donc (C90 6.8.3.2p2,
ANSI C 3.8.3.2p2) le comportement est explicitement indéfini.

Évidemment avec la plupart des préprocesseurs (ceux qui font du traitement
de texte pur, et pour qui l'opérateur ## se réduit à ne pas émettre de ' '
dans la sortie quand il y a doute ou ambiguïté), pas de problème, /lib/cpp
émet ==NAME, le compilateur va convertir le truc en deux lexèmes distincts
et roulemapoule ; par contre si le préprocesseur est plus intégré et la
sortie de cpp est passée directement, lexème par lexème, à l'analyse
syntaxique, ou bien si le préprocesseur est plus regardant (genre ucpp),
cela gueule voire cela plante.


Antoine

espie
Le #6923551
In article Antoine Leca
D'après Google tu n'es pas le seul avec ce souci.
cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id3304
htpp://gcc.gnu.org/ml/gcc-bugs/2007-09/msg00258.html
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01137.html
Vu que le problème a (au moins) 9 mois et est correctement reporté pour
autant que je puisse voir, on dirait pas que les mainteneurs de GCC ont
l'intention de faire des efforts supplémentaires pour le corriger.
Surtout qu'il y a un correctif évident, utiliser une version plus ancienne
de GCC pour compiler la bête de course.



Ca correspond a la fuite en avant actuelle de GCC. On laisse de plus en
plus tomber ce qui n'est pas standard, et on en arrive a ne plus compiler
sans gmake, et maintenant sans preprocesseur C99. Ca en devient absurde.

Entre ca et la GPLv3, souhaitons longue vie a LLVM (or whatever, j'ai
oublie le nom de ce nouveau truc), et esperons que gcc sera bientot mort
et enterre...

JKB
Le #6923541
Le 11-06-2008, à propos de
Re: Compilation de gcc 4.3.1 par Sun Studio 12 (Solaris),
Antoine Leca écrivait dans fr.comp.lang.c :
En news:, JKB va escriure:
1/ Sun Studio est installé correctement puisqu'il m'a permis de
compiler tous les prérequis sans problèmes ;
2/ l'étape de configuration est passée sans souci ;
3/ la compilation plante sur :


Quelle phase ? Je suppose la première (c'est-à-dire en utilisant les outils
natifs, "bootstrap"), mais bon...

C_COMMON_FIXED_TYPES (, fract);


D'après Google tu n'es pas le seul avec ce souci.
cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id3304
htpp://gcc.gnu.org/ml/gcc-bugs/2007-09/msg00258.html
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01137.html
Vu que le problème a (au moins) 9 mois et est correctement reporté pour
autant que je puisse voir, on dirait pas que les mainteneurs de GCC ont
l'intention de faire des efforts supplémentaires pour le corriger.
Surtout qu'il y a un correctif évident, utiliser une version plus ancienne
de GCC pour compiler la bête de course.


Le souci est que gcc-4.0 pose problème sur la machine en question.
Il est impossible de compiler un 4.3 depuis un 3.x de façon simple,
bref, je ne suis pas sorti de la mouise !...

Maintenant, si tu trouves une correction à appliquer au source, peut-être
qu'ils le prendront...



au détail près qu'un argument est nul et qu'il est utilisé dans la
macro comme suit :



Je rajoute devant :

#define C_COMMON_FIXED_TYPES(SAT,NAME)

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;


Et il faut donc savoir évaluer
== SAT ## NAME ## _type_node
quand SAT est vide. Si le préprocessur est conforme C99 (donc sait manipuler
les arguments vides, concept de "placeholders" dans la norme), pas de souci
; par contre, s'il est conforme à la norme C90, le SAT compte pour du
beurre, et l'évaluation de
== ## NAME
donne ==NAME, qui n'est pas un élément lexical correct, donc (C90 6.8.3.2p2,
ANSI C 3.8.3.2p2) le comportement est explicitement indéfini.

Évidemment avec la plupart des préprocesseurs (ceux qui font du traitement
de texte pur, et pour qui l'opérateur ## se réduit à ne pas émettre de ' '
dans la sortie quand il y a doute ou ambiguïté), pas de problème, /lib/cpp
émet ==NAME, le compilateur va convertir le truc en deux lexèmes distincts
et roulemapoule ; par contre si le préprocesseur est plus intégré et la
sortie de cpp est passée directement, lexème par lexème, à l'analyse
syntaxique, ou bien si le préprocesseur est plus regardant (genre ucpp),
cela gueule voire cela plante.


Bon, je vais de ce pas chercher un préprocesseur C99...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


Antoine Leca
Le #6986481
En news:, JKB va escriure:

Bon, je vais de ce pas chercher un préprocesseur C99...


Euh, si tu peux modifier ta chaîne pour mettre le préprocesseur qui
t'arrange (-Yp,xxx peut être ?), alors une manière plus simple devrait être
de forcer à utiliser le /lib/cpp de ta machine... De cette façon, tu vas
casser le lien direct entre cpp et l'analyseur syntaxique (en forçant à
passer par un fichier .i intermédiaire), et tu devrais de cette façon passer
outre le plantage (OK, peut-être que cpp va râler, mais au point où on
est...)

Évidemment, tu ajustes le chemin pour aller chercher le préprocesseur
attendu (je sais que Sun a/avait la manie de mettre les outils de
développement dans des coins réellement bizarres).

Par ailleurs, en fait quasiment n'importe quel préprocesseur pourrait faire
l'affaire ; et un préprocesseur réellement C99 comme ucpp va accrocher (cf.
mon autre message), alors que d'autres comme les anciennes versions de GCC
(cccp) ou celui de DMR, pour citer deux préprocesseurs courants (= que je
connais), vont digérer probablement sans souci la soupe, écrire un joli .i
sur le disque avec ==frac bien collés ;-), que cc1 va ensuite pouvoir relire
comme deux lexèmes distincts sans voir l'astuce.


Antoine

JKB
Le #6986471
Le 12-06-2008, à propos de
Re: Compilation de gcc 4.3.1 par Sun Studio 12 (Solaris),
Antoine Leca écrivait dans fr.comp.lang.c :
En news:, JKB va escriure:

Bon, je vais de ce pas chercher un préprocesseur C99...


Euh, si tu peux modifier ta chaîne pour mettre le préprocesseur qui
t'arrange (-Yp,xxx peut être ?), alors une manière plus simple devrait être
de forcer à utiliser le /lib/cpp de ta machine... De cette façon, tu vas
casser le lien direct entre cpp et l'analyseur syntaxique (en forçant à
passer par un fichier .i intermédiaire), et tu devrais de cette façon passer
outre le plantage (OK, peut-être que cpp va râler, mais au point où on
est...)

Évidemment, tu ajustes le chemin pour aller chercher le préprocesseur
attendu (je sais que Sun a/avait la manie de mettre les outils de
développement dans des coins réellement bizarres).

Par ailleurs, en fait quasiment n'importe quel préprocesseur pourrait faire
l'affaire ; et un préprocesseur réellement C99 comme ucpp va accrocher (cf.
mon autre message), alors que d'autres comme les anciennes versions de GCC
(cccp) ou celui de DMR, pour citer deux préprocesseurs courants (= que je
connais), vont digérer probablement sans souci la soupe, écrire un joli .i
sur le disque avec ==frac bien collés ;-), que cc1 va ensuite pouvoir relire
comme deux lexèmes distincts sans voir l'astuce.


J'ai bootstrapé gcc avec un gcc-2.8 que sun studio a bien voulu
compiler pour bootstraper ensuite gcc-4.3.1 par ce 2.8 et toule ma
poule... Encore un truc simple...

Merci pour tout,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


Publicité
Poster une réponse
Anonyme