size_t ne peut pas être trouvé par g ++ - 4.1 ou autres sur Ubuntu 8.1

Cela m'est déjà arrivé, mais je ne me souviens plus comment je l'ai corrigé.size_t ne peut pas être trouvé par g ++ - 4.1 ou autres sur Ubuntu 8.1

Je ne peux pas compiler certains programmes ici sur une nouvelle installation Ubuntu ... Quelque chose ne va pas avec mes en-têtes.

J'ai essayé g ++ - 4.1 et 4.3 en vain.

g++ -g -frepo -DIZ_LINUX -I/usr/include/linux -I/usr/include -I/include -c qlisttest.cpp 
/usr/include/libio.h:332: error: ‘size_t’ does not name a type 
/usr/include/libio.h:336: error: ‘size_t’ was not declared in this scope 
/usr/include/libio.h:364: error: ‘size_t’ has not been declared 
/usr/include/libio.h:373: error: ‘size_t’ has not been declared 
/usr/include/libio.h:493: error: ‘size_t’ does not name a type 
/usr/include/stdio.h:294: error: ‘size_t’ has not been declared 
...

le fichier ...

#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 
#include <unistd.h> 
... 



@ubuntu:~/work/zpk/src$ cat /usr/include/linux/types.h | grep size_t 
typedef __kernel_size_t size_t; 
typedef __kernel_ssize_t ssize_t;

types.h est sans aucun doute dans le chemin, et se ramassé. J'ai vérifié en changeant le nom de fichier et obtiens une erreur son manque ...

Est-ce que n'importe qui a des idées ...? J'apprécierais vraiment l'aide ...

Source

2009-07-10 EdH

Commencez par enlever -I/usr/include/linux et -I/usr/include. L'ajout de répertoires système pour inclure manuellement les chemins n'a aucun effet ou casse les choses. En outre, supprimez -frepo pour plus de sécurité.

Source

2009-07-10 07:26:45

Il est difficile de dire quel est le problème sans voir votre source complète. La meilleure façon de déboguer des problèmes de ce type est d'utiliser le paramètre "-E" de g ++ pour produire une sortie de pré-processeur, puis de regarder cela pour comprendre ce qui se passe dans vos inclusions. Voici ce que la page d'informations g ++ dit à propos de "-E":

-E Arrêt après l'étape de prétraitement; ne lancez pas le compilateur proprement dit. La sortie est sous la forme d'un code source prétraité, qui est envoyé à la sortie standard.

Aussi, pourquoi ne pas simplement inclure sys/types.h en haut du fichier?

Addendum:

Sur mon système, j'ai créé un petit fichier appelé foo.cc qui ne contient que:

#include <time.h>

Et puis j'ai couru:

g ++ -E /tmp/foo.cc> /tmp/foo.pp

En regardant cette sortie dans beaucoup de détails est v très important. Par exemple, j'ai appris que /usr/include/bits/types.h a un typedef pour __time_t, et que /usr/include/types.h utilise ensuite ce typedef pour dire "typedef __time_t time_t". Mais, il y a d'autres macros intéressantes autour de cette définition. Portez une attention particulière à des choses comme la macro "__BEGIN_NAMESPACE_STD" dans /usr/include/time.h, qui sur mon système semble être une définition vide. Mais, je peux imaginer que d'autres systèmes peuvent avoir une valeur différente pour cette macro, forçant la définition de time_t dans un autre espace de noms.

Lisez la page d'informations Cpp, section "9 Sortie du préprocesseur" qui définit le format des lignes du fichier. On notera en particulier la section sur:

nom de fichier source et informations numéro de ligne est transmis par des lignes de la forme

# lineNum FILENAME DRAPEAUX

Et puis se poursuit pour décrire « FLAGS "qui sont d'intérêt pour ce niveau de débogage.

Source

2009-07-10 06:17:41 slacy

merci ... J'ai essayé d'ajouter sys/types.h et types.h en vain. mais -E est certainement utile - un grep sur celui pour size_t et je ne peux pas trouver un typedef pour cela .... hmm – EdH

Une autre chose à essayer serait de comparer la sortie de "gcc -E /tmp/foo.c "et" g ++ -E /tmp/foo.cc "Le premier appelle le compilateur C et le dernier le compilateur C++. (foo.c et foo.cc ne devraient avoir rien d'autre que "#include " – slacy

Généralement, vous ne devriez pas utiliser les fichiers C .h pour C++. Bien que vous puissiez trouver un moyen facile d'y échapper, et bien que cela soit autorisé dans les versions précédentes de g ++ et dans d'autres compilateurs, la norme C++ définit size_t comme étant dans cstddef (voir section 18.2/tableau 17). g ++ est de plus en plus strict.

Retirez tous les chemins que vous avez comprend ajoutés à votre commande (ils sont redondants), et ajouter à la partie supérieure de votre code source si non inclus:

#include <cstddef> 
using namespace std;

Source

2009-07-10 06:57:27

Ceci n'est pas vrai Les en-têtes C sont autorisés dans les unités de traduction C++, et il n'est même pas nécessaire d'utiliser des équivalents C++ comme cstddef –

Référence sur la raison pour laquelle vous pensez que les équivalents C++ sont inutiles Tous ces développeurs de compilateurs C++ perdent vraiment leur temps? –

cstddef est comme stddef.h sauf que cstddef est dans l'espace de noms std. Les équivalents C++ sont plus pratiques pour éviter la pollution des espaces de noms, –

Avez-vous installé le package build-essential?

sudo apt-get install build-essential

Source

2009-07-10 16:59:36 kalleh

Oui j'avais. mais vous en avez certainement besoin à coup sûr. Merci. – EdH

Il devrait être dans stddef.h ou cstddef. types.h n'est pas une bibliothèque standard, et je crois que cela fait référence aux types de systèmes d'exploitation nécessaires.

Source

2009-07-10 17:34:35

Oublié de faire un suivi à ce sujet. Il s'avère que /usr/include ne peut pas être inclus avec /usr/include/linux sur cette distribution particulière. size_t semble être éliminé par la deuxième comprend.

Mes inclusions sont maintenant simplement /usr/include et cela fonctionne très bien. En retirant toutes les inclusions et en jouant avec elles, vous avez corrigé le problème.

Source

2009-07-18 17:30:23 EdH

size_t ne peut pas être trouvé par g ++ - 4.1 ou autres sur Ubuntu 8.1

Répondre

Questions connexes