db_core.cc:14:1: warning: "major" redefined
In file included from /usr/include/sys/types.h:219,
from /usr/include/stdlib.h:433,
from
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/cstdlib:52,
from
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:67,
from
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:46,
from
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/string:47,
from db_core.hh:9,
from db_core.cc:6:
/usr/include/sys/sysmacros.h:64:1: warning: this is the location of the
previous definition
Ma question est en fait : peut-on considérer cela comme un bug de gcc
(l'inclusion de cstdlib et non stdlib.h devrait me protéger de ce genre
de surprise), et dois-je en faire un bug-report ?
| Bonjour, | | Alors que je définissais tranquillement une classe ressemblant à ceci : | | class version { | int major; | int minor; | int release; | }; | | Je me suis rendu compte que des macros "major" et "minor" exitaient et | étaient substituées en "gnu_dev_major" et "gnu_dev_minor". | | L'include incriminé est... string (indirectement) !
<string.h> ou <string> ou <stdlib.h> ?
quelle version de GCC ?
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et 4.0.x) ne se comporte aussi étrangement.
-- Gaby
Christophe de VIENNE <cdevienne@alphacent.com> writes:
| Bonjour,
|
| Alors que je définissais tranquillement une classe ressemblant à ceci :
|
| class version {
| int major;
| int minor;
| int release;
| };
|
| Je me suis rendu compte que des macros "major" et "minor" exitaient et
| étaient substituées en "gnu_dev_major" et "gnu_dev_minor".
|
| L'include incriminé est... string (indirectement) !
<string.h> ou <string> ou <stdlib.h> ?
quelle version de GCC ?
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et 4.0.x) ne
se comporte aussi étrangement.
| Bonjour, | | Alors que je définissais tranquillement une classe ressemblant à ceci : | | class version { | int major; | int minor; | int release; | }; | | Je me suis rendu compte que des macros "major" et "minor" exitaient et | étaient substituées en "gnu_dev_major" et "gnu_dev_minor". | | L'include incriminé est... string (indirectement) !
<string.h> ou <string> ou <stdlib.h> ?
quelle version de GCC ?
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et 4.0.x) ne se comporte aussi étrangement.
[ ~]$ g++ -E -o test.ii test.h test.h:3:1: attention : "major" redefined Dans le fichier inclus à partir de /usr/include/sys/types.h:219, à partir de /usr/include/stdlib.h:433, à partir de /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/cstdlib:52, à partir de test.h:1: /usr/include/sys/sysmacros.h:64:1: attention : this is the location of the previous definition
A+
Christophe
-- Christophe de Vienne
Gabriel Dos Reis wrote:
Christophe de VIENNE <cdevienne@alphacent.com> writes:
[cdevienne@luciole ~]$ g++ -E -o test.ii test.h
test.h:3:1: attention : "major" redefined
Dans le fichier inclus à partir de /usr/include/sys/types.h:219,
à partir de /usr/include/stdlib.h:433,
à partir de
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/cstdlib:52,
à partir de test.h:1:
/usr/include/sys/sysmacros.h:64:1: attention : this is the location of
the previous definition
[ ~]$ g++ -E -o test.ii test.h test.h:3:1: attention : "major" redefined Dans le fichier inclus à partir de /usr/include/sys/types.h:219, à partir de /usr/include/stdlib.h:433, à partir de /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/cstdlib:52, à partir de test.h:1: /usr/include/sys/sysmacros.h:64:1: attention : this is the location of the previous definition
A+
Christophe
-- Christophe de Vienne
James Kanze
Gabriel Dos Reis wrote:
Christophe de VIENNE writes:
| Alors que je définissais tranquillement une classe ressemblant à ceci :
| class version { | int major; | int minor; | int release; | };
| Je me suis rendu compte que des macros "major" et "minor" | exitaient et étaient substituées en "gnu_dev_major" et | "gnu_dev_minor".
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et 4.0.x) ne se comporte aussi étrangement.
Surtout, sur quel système, et avec quelles options de compilation ?
Certains vieux Unix avait des macros pour major et minor dans stat.h (ou un en-tête qu'il incluait, peut-être sys/types.h). Ce n'est pas standard selon Posix, mais c'est possible que certains systèmes continuent de les supporter pour des raisons historiques, au moins avec certaines combinaisons des options -D. Or, ça ne m'étonnerait pas que par un chemin indirect, certains en-têtes de g++ finissent par inclure l'en-tête en question.
(Note bien cependant que ce n'est que de la spéculation de ma part. Comme toi, je n'ai jamais vu le problème moi-même.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
Christophe de VIENNE <cdevienne@alphacent.com> writes:
| Alors que je définissais tranquillement une classe ressemblant à ceci :
| class version {
| int major;
| int minor;
| int release;
| };
| Je me suis rendu compte que des macros "major" et "minor"
| exitaient et étaient substituées en "gnu_dev_major" et
| "gnu_dev_minor".
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et
4.0.x) ne se comporte aussi étrangement.
Surtout, sur quel système, et avec quelles options de
compilation ?
Certains vieux Unix avait des macros pour major et minor dans
stat.h (ou un en-tête qu'il incluait, peut-être sys/types.h). Ce
n'est pas standard selon Posix, mais c'est possible que certains
systèmes continuent de les supporter pour des raisons
historiques, au moins avec certaines combinaisons des options
-D. Or, ça ne m'étonnerait pas que par un chemin indirect,
certains en-têtes de g++ finissent par inclure l'en-tête en
question.
(Note bien cependant que ce n'est que de la spéculation de ma
part. Comme toi, je n'ai jamais vu le problème moi-même.)
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et 4.0.x) ne se comporte aussi étrangement.
Surtout, sur quel système, et avec quelles options de compilation ?
Certains vieux Unix avait des macros pour major et minor dans stat.h (ou un en-tête qu'il incluait, peut-être sys/types.h). Ce n'est pas standard selon Posix, mais c'est possible que certains systèmes continuent de les supporter pour des raisons historiques, au moins avec certaines combinaisons des options -D. Or, ça ne m'étonnerait pas que par un chemin indirect, certains en-têtes de g++ finissent par inclure l'en-tête en question.
(Note bien cependant que ce n'est que de la spéculation de ma part. Comme toi, je n'ai jamais vu le problème moi-même.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
James Kanze wrote:
Gabriel Dos Reis wrote:
Christophe de VIENNE writes:
| Alors que je définissais tranquillement une classe | ressemblant à ceci :
| class version { | int major; | int minor; | int release; | };
| Je me suis rendu compte que des macros "major" et "minor" | exitaient et étaient substituées en "gnu_dev_major" et | "gnu_dev_minor".
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et 4.0.x) ne se comporte aussi étrangement.
Surtout, sur quel système, et avec quelles options de compilation ?
Certains vieux Unix avait des macros pour major et minor dans stat.h (ou un en-tête qu'il incluait, peut-être sys/types.h). Ce n'est pas standard selon Posix, mais c'est possible que certains systèmes continuent de les supporter pour des raisons historiques, au moins avec certaines combinaisons des options -D. Or, ça ne m'étonnerait pas que par un chemin indirect, certains en-têtes de g++ finissent par inclure l'en-tête en question.
(Note bien cependant que ce n'est que de la spéculation de ma part. Comme toi, je n'ai jamais vu le problème moi-même.)
Correction. Je viens de faire l'essai moi-même sous Linux, et il y a effectivement des macros de ce nom dans /usr/include/sys/sysmacros.h. Ce n'est donc pas un ancien système, mais quelque chose de tout récent.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans /opt sur mon système). Ce n'est pas un fichier installé par g++. Le copyright dit bien lib C du compilateur C de GNU, mais la version que j'ai fait partie de la distribution Linux, et non gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou, d'autant plus que je ne trouve pas de fichier de ce nom dans la distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai généré le compilateur.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze wrote:
Gabriel Dos Reis wrote:
Christophe de VIENNE <cdevienne@alphacent.com> writes:
| Alors que je définissais tranquillement une classe
| ressemblant à ceci :
| class version {
| int major;
| int minor;
| int release;
| };
| Je me suis rendu compte que des macros "major" et "minor"
| exitaient et étaient substituées en "gnu_dev_major" et
| "gnu_dev_minor".
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et
4.0.x) ne se comporte aussi étrangement.
Surtout, sur quel système, et avec quelles options de
compilation ?
Certains vieux Unix avait des macros pour major et minor dans
stat.h (ou un en-tête qu'il incluait, peut-être sys/types.h).
Ce n'est pas standard selon Posix, mais c'est possible que
certains systèmes continuent de les supporter pour des raisons
historiques, au moins avec certaines combinaisons des options
-D. Or, ça ne m'étonnerait pas que par un chemin indirect,
certains en-têtes de g++ finissent par inclure l'en-tête en
question.
(Note bien cependant que ce n'est que de la spéculation de ma
part. Comme toi, je n'ai jamais vu le problème moi-même.)
Correction. Je viens de faire l'essai moi-même sous Linux, et il
y a effectivement des macros de ce nom dans
/usr/include/sys/sysmacros.h. Ce n'est donc pas un ancien
système, mais quelque chose de tout récent.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans
/opt sur mon système). Ce n'est pas un fichier installé par g++.
Le copyright dit bien lib C du compilateur C de GNU, mais la
version que j'ai fait partie de la distribution Linux, et non
gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou,
d'autant plus que je ne trouve pas de fichier de ce nom dans la
distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai
généré le compilateur.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
aucune des versions que j'ai à ma portée (3.3.x, 3.4.x et 4.0.x) ne se comporte aussi étrangement.
Surtout, sur quel système, et avec quelles options de compilation ?
Certains vieux Unix avait des macros pour major et minor dans stat.h (ou un en-tête qu'il incluait, peut-être sys/types.h). Ce n'est pas standard selon Posix, mais c'est possible que certains systèmes continuent de les supporter pour des raisons historiques, au moins avec certaines combinaisons des options -D. Or, ça ne m'étonnerait pas que par un chemin indirect, certains en-têtes de g++ finissent par inclure l'en-tête en question.
(Note bien cependant que ce n'est que de la spéculation de ma part. Comme toi, je n'ai jamais vu le problème moi-même.)
Correction. Je viens de faire l'essai moi-même sous Linux, et il y a effectivement des macros de ce nom dans /usr/include/sys/sysmacros.h. Ce n'est donc pas un ancien système, mais quelque chose de tout récent.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans /opt sur mon système). Ce n'est pas un fichier installé par g++. Le copyright dit bien lib C du compilateur C de GNU, mais la version que j'ai fait partie de la distribution Linux, et non gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou, d'autant plus que je ne trouve pas de fichier de ce nom dans la distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai généré le compilateur.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Christophe de VIENNE
James Kanze wrote:
Correction. Je viens de faire l'essai moi-même sous Linux, et il y a effectivement des macros de ce nom dans /usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Ce n'est donc pas un ancien système, mais quelque chose de tout récent.
Mon système est en effet assez à jour.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans /opt sur mon système). Ce n'est pas un fichier installé par g++. Le copyright dit bien lib C du compilateur C de GNU, mais la version que j'ai fait partie de la distribution Linux, et non gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou, d'autant plus que je ne trouve pas de fichier de ce nom dans la distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai généré le compilateur.
Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor étant des noms de variables potentiels. Le problème est que je ne sais pas trop à qui remonter ce problème. Au projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc ? au autre encore ?
A+
Christophe
-- Christophe de Vienne
James Kanze wrote:
Correction. Je viens de faire l'essai moi-même sous Linux, et il
y a effectivement des macros de ce nom dans
/usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Ce n'est donc pas un ancien
système, mais quelque chose de tout récent.
Mon système est en effet assez à jour.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans
/opt sur mon système). Ce n'est pas un fichier installé par g++.
Le copyright dit bien lib C du compilateur C de GNU, mais la
version que j'ai fait partie de la distribution Linux, et non
gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou,
d'autant plus que je ne trouve pas de fichier de ce nom dans la
distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai
généré le compilateur.
Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor
étant des noms de variables potentiels.
Le problème est que je ne sais pas trop à qui remonter ce problème. Au
projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc
? au autre encore ?
Correction. Je viens de faire l'essai moi-même sous Linux, et il y a effectivement des macros de ce nom dans /usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Ce n'est donc pas un ancien système, mais quelque chose de tout récent.
Mon système est en effet assez à jour.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans /opt sur mon système). Ce n'est pas un fichier installé par g++. Le copyright dit bien lib C du compilateur C de GNU, mais la version que j'ai fait partie de la distribution Linux, et non gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou, d'autant plus que je ne trouve pas de fichier de ce nom dans la distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai généré le compilateur.
Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor étant des noms de variables potentiels. Le problème est que je ne sais pas trop à qui remonter ce problème. Au projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc ? au autre encore ?
A+
Christophe
-- Christophe de Vienne
usenet5
Christophe de VIENNE :
| Le problème est que je ne sais pas trop à qui remonter ce problème. Au | projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc | ? au autre encore ?
Plutôt à ta distribution, et ce sont les mainteneurs de ces programmes qui ensuite transmettront le problème aux développeurs amont s'il y a lieu.
Christophe de VIENNE <cdevienne@alphacent.com> :
| Le problème est que je ne sais pas trop à qui remonter ce problème. Au
| projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc
| ? au autre encore ?
Plutôt à ta distribution, et ce sont les mainteneurs de ces programmes
qui ensuite transmettront le problème aux développeurs amont s'il y a
lieu.
| Le problème est que je ne sais pas trop à qui remonter ce problème. Au | projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc | ? au autre encore ?
Plutôt à ta distribution, et ce sont les mainteneurs de ces programmes qui ensuite transmettront le problème aux développeurs amont s'il y a lieu.
Gabriel Dos Reis
Christophe de VIENNE writes:
[...]
| Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor | étant des noms de variables potentiels.
Oui.
| Le problème est que je ne sais pas trop à qui remonter ce problème. Au | projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc | ? au autre encore ?
à ton distributeur de linux -- si tu le rapportes à GCC, il est probable que les bugmasters s'en foutent parce que ce n'est pas quelque chose que GCC définit et GCC n'a aucun contrôle dessus.
Je suis moi-même tombé sur un problème similaire (mais avec "likely" et "unlikely") en essayant de compiler le système Axiom
http://www.axiom-developer.org/
sur mon linux favori. Après quelques heures de frustration, j'ai découvert que quelques génies de la glibc ont décidé de définir ces noms en tant que macros (et Axiom aussi !) et avec les bonnes combinaisons de circonstance, cela donne de jolis puzzles :-(
Vivement #nospam.
-- Gaby
Christophe de VIENNE <cdevienne@alphacent.com> writes:
[...]
| Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor
| étant des noms de variables potentiels.
Oui.
| Le problème est que je ne sais pas trop à qui remonter ce problème. Au
| projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc
| ? au autre encore ?
à ton distributeur de linux -- si tu le rapportes à GCC, il est
probable que les bugmasters s'en foutent parce que ce n'est pas
quelque chose que GCC définit et GCC n'a aucun contrôle dessus.
Je suis moi-même tombé sur un problème similaire (mais avec "likely" et
"unlikely") en essayant de compiler le système Axiom
http://www.axiom-developer.org/
sur mon linux favori. Après quelques heures de frustration, j'ai
découvert que quelques génies de la glibc ont décidé de définir ces
noms en tant que macros (et Axiom aussi !) et avec les bonnes
combinaisons de circonstance, cela donne de jolis puzzles :-(
| Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor | étant des noms de variables potentiels.
Oui.
| Le problème est que je ne sais pas trop à qui remonter ce problème. Au | projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc | ? au autre encore ?
à ton distributeur de linux -- si tu le rapportes à GCC, il est probable que les bugmasters s'en foutent parce que ce n'est pas quelque chose que GCC définit et GCC n'a aucun contrôle dessus.
Je suis moi-même tombé sur un problème similaire (mais avec "likely" et "unlikely") en essayant de compiler le système Axiom
http://www.axiom-developer.org/
sur mon linux favori. Après quelques heures de frustration, j'ai découvert que quelques génies de la glibc ont décidé de définir ces noms en tant que macros (et Axiom aussi !) et avec les bonnes combinaisons de circonstance, cela donne de jolis puzzles :-(
Vivement #nospam.
-- Gaby
kanze
Christophe de VIENNE wrote:
James Kanze wrote:
Correction. Je viens de faire l'essai moi-même sous Linux, et il y a effectivement des macros de ce nom dans
/usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Ce n'est donc pas un ancien système, mais quelque chose de tout récent.
Mon système est en effet assez à jour.
Ce n'est pas une question d'être à jour. Ces macros était bien présents dans des variantes anciennes de Unix -- on pourrait comprendre qu'un vendeur qui livrait ces variantes quand elles étaient courantes veut encore supporter le code écrit pour des systèmes de l'époque (encore que... c'est vraiment ancien).
Linux ne fait pas partie des vendeurs qui livrait de ces systèmes.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans /opt sur mon système). Ce n'est pas un fichier installé par g++. Le copyright dit bien lib C du compilateur C de GNU, mais la version que j'ai fait partie de la distribution Linux, et non gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou, d'autant plus que je ne trouve pas de fichier de ce nom dans la distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai généré le compilateur.
Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor étant des noms de variables potentiels.
Tout à fait.
Ils sont présents sous Solaris. Il y a aussi un commentaire qui dit qu'ils seront enlevés lors de la « next major release » (mais les copyright dans le fichier sont de AT&T, et s'arrête à 1989, et il y en a eu des releases depuis). Mais ce fichier n'est inclu par aucun autre -- tu n'as les macros que si toi, tu l'inclus directement. (Et d'après son contenu, j'ai l'impression qu'il sert surtout quand tu écris des pilotes de périphérique, ou de telles choses.)
La question alors est : pourquoi est-ce qu'il est inclu depuis <cstdlib> ? Il y a une erreur là.
Le problème est que je ne sais pas trop à qui remonter ce problème. Au projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc ? au autre encore ?
Dans la mésure où le problème est indépendant de gcc, et touchera tout compilateur C sur le système, dès que le programme inclu <stdlib.h>, je mettrais d'abord Linux en cause. Après tout, c'est à eux de fournir les en-têtes corrects.
Ceci dit, je signalerais le problème à gcc aussi, quand même. À la rigueur, même s'ils ne sont pas à l'origine du problème, il pourrait vouloir le corriger, ou au moins chercher un work-around.
D'autant plus qu'il y a des boîtes où on compilent avec des options -Dmajor=2 -Dminor=3, pour la version no. 2.3.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Christophe de VIENNE wrote:
James Kanze wrote:
Correction. Je viens de faire l'essai moi-même sous Linux,
et il y a effectivement des macros de ce nom dans
/usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Ce n'est donc pas un ancien système, mais quelque chose de
tout récent.
Mon système est en effet assez à jour.
Ce n'est pas une question d'être à jour. Ces macros était bien
présents dans des variantes anciennes de Unix -- on pourrait
comprendre qu'un vendeur qui livrait ces variantes quand elles
étaient courantes veut encore supporter le code écrit pour des
systèmes de l'époque (encore que... c'est vraiment ancien).
Linux ne fait pas partie des vendeurs qui livrait de ces
systèmes.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est
dans /opt sur mon système). Ce n'est pas un fichier installé
par g++. Le copyright dit bien lib C du compilateur C de
GNU, mais la version que j'ai fait partie de la distribution
Linux, et non gcc. Je n'exclurais pas que quelqu'un de Linux
a fait joujou, d'autant plus que je ne trouve pas de fichier
de ce nom dans la distribution de g++ 3.4.3, ni dans le
répertoire objet où j'ai généré le compilateur.
Quoi qu'il en soit je trouve cela un peu génant, les mots
major et minor étant des noms de variables potentiels.
Tout à fait.
Ils sont présents sous Solaris. Il y a aussi un commentaire qui
dit qu'ils seront enlevés lors de la « next major release »
(mais les copyright dans le fichier sont de AT&T, et s'arrête à
1989, et il y en a eu des releases depuis). Mais ce fichier
n'est inclu par aucun autre -- tu n'as les macros que si toi, tu
l'inclus directement. (Et d'après son contenu, j'ai l'impression
qu'il sert surtout quand tu écris des pilotes de périphérique,
ou de telles choses.)
La question alors est : pourquoi est-ce qu'il est inclu depuis
<cstdlib> ? Il y a une erreur là.
Le problème est que je ne sais pas trop à qui remonter ce
problème. Au projet gcc pour que cstdlib nettoie comme il faut
ces macros ? ou glibc ? au autre encore ?
Dans la mésure où le problème est indépendant de gcc, et
touchera tout compilateur C sur le système, dès que le programme
inclu <stdlib.h>, je mettrais d'abord Linux en cause. Après
tout, c'est à eux de fournir les en-têtes corrects.
Ceci dit, je signalerais le problème à gcc aussi, quand même. À
la rigueur, même s'ils ne sont pas à l'origine du problème, il
pourrait vouloir le corriger, ou au moins chercher un
work-around.
D'autant plus qu'il y a des boîtes où on compilent avec des
options -Dmajor=2 -Dminor=3, pour la version no. 2.3.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Correction. Je viens de faire l'essai moi-même sous Linux, et il y a effectivement des macros de ce nom dans
/usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Ce n'est donc pas un ancien système, mais quelque chose de tout récent.
Mon système est en effet assez à jour.
Ce n'est pas une question d'être à jour. Ces macros était bien présents dans des variantes anciennes de Unix -- on pourrait comprendre qu'un vendeur qui livrait ces variantes quand elles étaient courantes veut encore supporter le code écrit pour des systèmes de l'époque (encore que... c'est vraiment ancien).
Linux ne fait pas partie des vendeurs qui livrait de ces systèmes.
Toujours est-il qu'il s'agit d'un en-tête système (g++ est dans /opt sur mon système). Ce n'est pas un fichier installé par g++. Le copyright dit bien lib C du compilateur C de GNU, mais la version que j'ai fait partie de la distribution Linux, et non gcc. Je n'exclurais pas que quelqu'un de Linux a fait joujou, d'autant plus que je ne trouve pas de fichier de ce nom dans la distribution de g++ 3.4.3, ni dans le répertoire objet où j'ai généré le compilateur.
Quoi qu'il en soit je trouve cela un peu génant, les mots major et minor étant des noms de variables potentiels.
Tout à fait.
Ils sont présents sous Solaris. Il y a aussi un commentaire qui dit qu'ils seront enlevés lors de la « next major release » (mais les copyright dans le fichier sont de AT&T, et s'arrête à 1989, et il y en a eu des releases depuis). Mais ce fichier n'est inclu par aucun autre -- tu n'as les macros que si toi, tu l'inclus directement. (Et d'après son contenu, j'ai l'impression qu'il sert surtout quand tu écris des pilotes de périphérique, ou de telles choses.)
La question alors est : pourquoi est-ce qu'il est inclu depuis <cstdlib> ? Il y a une erreur là.
Le problème est que je ne sais pas trop à qui remonter ce problème. Au projet gcc pour que cstdlib nettoie comme il faut ces macros ? ou glibc ? au autre encore ?
Dans la mésure où le problème est indépendant de gcc, et touchera tout compilateur C sur le système, dès que le programme inclu <stdlib.h>, je mettrais d'abord Linux en cause. Après tout, c'est à eux de fournir les en-têtes corrects.
Ceci dit, je signalerais le problème à gcc aussi, quand même. À la rigueur, même s'ils ne sont pas à l'origine du problème, il pourrait vouloir le corriger, ou au moins chercher un work-around.
D'autant plus qu'il y a des boîtes où on compilent avec des options -Dmajor=2 -Dminor=3, pour la version no. 2.3.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Thomas Labourdette
Christophe de VIENNE a écrit le Mercredi 23 Mars 2005 09:51 :
James Kanze wrote:
Correction. Je viens de faire l'essai moi-même sous Linux, et il y a effectivement des macros de ce nom dans /usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Chez moi (Debian/Linux) ce fichier est inclus via sys/types.h uniquement si __USE_BSD est définit.
@+ -- Éve ENGILE (signature aléatoire) BAC : - Les 4 points cardinaux sont la droite, la gauche, le bas et le haut.
Christophe de VIENNE a écrit le Mercredi 23 Mars 2005 09:51 :
James Kanze wrote:
Correction. Je viens de faire l'essai moi-même sous Linux, et il
y a effectivement des macros de ce nom dans
/usr/include/sys/sysmacros.h.
C'est bien là qu'il est défini chez moi.
Chez moi (Debian/Linux) ce fichier est inclus via sys/types.h uniquement si
__USE_BSD est définit.
@+
--
Éve ENGILE (signature aléatoire)
BAC :
- Les 4 points cardinaux sont la droite, la gauche, le bas et le haut.
