size_t no puede ser encontrado por g ++ - 4.1 u otros en Ubuntu 8.1

Esto me ha pasado antes, pero no recuerdo cómo lo arreglé.size_t no puede ser encontrado por g ++ - 4.1 u otros en Ubuntu 8.1

No puedo compilar algunos programas aquí en una nueva instalación de Ubuntu ... Algo anda mal con mis encabezados.

He intentado g ++ - 4.1 y 4.3 inútilmente.

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 
...

el archivo ...

#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á definitivamente en el camino, y es para ser recogido. Lo verifiqué cambiando el nombre del archivo y me perdí el error ...

¿Alguien tiene alguna idea ...? Realmente agradecería la ayuda ...

Fuente

2009-07-10 EdH

de inicio mediante la eliminación -I/usr/include/linux y -I/usr/include. Agregar directorios de sistema para incluir rutas manualmente no tiene ningún efecto o rompe cosas. Además, elimine -frepo para mayor seguridad.

Fuente

2009-07-10 07:26:45

Es difícil decir cuál es el problema sin ver su fuente completa. La mejor manera de solucionar problemas como este es usar el parámetro "-E" de g ++ para producir resultados del preprocesador, y luego ver eso para descubrir qué está sucediendo en sus inclusiones. Esto es lo que dice la página de información de g ++ sobre "-E":

-E Detener después de la etapa de preprocesamiento; no ejecute el compilador propiamente La salida es en forma de código fuente preprocesado, que es enviado a la salida estándar.

Además, ¿por qué no simplemente incluir sys/types.h en la parte superior del archivo?

Adición:

En mi sistema, he creado un archivo llamado corto foo.cc que contiene solamente:

#include <time.h>

Y entonces me he encontrado:

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

Mirando esta salida con mucho detalle es v ery importante. Por ejemplo, aprendí que /usr/include/bits/types.h tiene un typedef para __time_t, y que /usr/include/types.h usa ese tipodef para decir "typedef __time_t time_t". Pero, hay otras macros interesantes que rodean esa definición. Preste especial atención a cosas como la macro "__BEGIN_NAMESPACE_STD" en /usr/include/time.h, que en mi sistema parece ser una definición vacía. Pero, me puedo imaginar que algunos otros sistemas pueden tener un valor diferente para esta macro, forzando la definición de time_t en algún otro espacio de nombres.

Lea la página de información de Cpp, sección "Salida del preprocesador 9" que define el formato de las líneas del archivo. De particular interés es la sección en:

Fuente nombre de archivo y el número de teléfono de información es transportada por las líneas de la forma

# lineNum FLAGS FILENAME

y luego se va a describir "BANDERAS "que son de interés para este nivel de depuración".

Fuente

2009-07-10 06:17:41 slacy

gracias ... He intentado agregar sys/types.h y types.h en vano. pero -E es definitivamente útil - un grep en eso para size_t y no puedo encontrar un typedef para ello .... hmm – EdH

Otra cosa que probar sería comparar la salida de "gcc -E /tmp/foo.c "y" g ++ -E /tmp/foo.cc ". El primero invoca el compilador de C y el último el compilador de C++. (foo.c y foo.cc no deberían tener nada más que "#include ". – slacy

En general, no debe utilizar archivos C .h para C++. Si bien puede encontrar una forma fácil de salirse con la suya, y aunque se permitió mucho de esto en versiones anteriores de g ++ y en otros compiladores, el estándar de C++ define size_t para estar en cstddef (consulte la sección 18.2/tabla 17). g ++ ha sido cada vez más estricto.

Retire toda la incluye caminos que ha añadido a su comando (que son redundantes), y añadir a la parte superior de su código fuente si no está incluido:

#include <cstddef> 
using namespace std;

Fuente

2009-07-10 06:57:27

Esto no es cierto. Los encabezados C están permitidos en unidades de traducción C++, y no es necesario ni siquiera molestarse en usar equivalentes de C++ como cstddef. –

Por favor cite a referencia sobre por qué crees que los equivalentes de C++ son innecesarios. ¿Están todos estos desarrolladores de compiladores de C++ perdiendo su tiempo? –

cstddef es como stddef.h excepto que cstddef está en el espacio de nombres std. Los equivalentes de C++ son más convenientes para evitar la contaminación del espacio de nombres. eso es todo. –

¿Has instalado el paquete build-essential?

sudo apt-get install build-essential

Fuente

2009-07-10 16:59:36 kalleh

Sí, lo tuve. pero definitivamente necesitas esto con seguridad. Gracias. – EdH

Debe estar en stddef.h o cstddef. types.h no es una biblioteca estándar, y creo que se refiere a los tipos que el sistema operativo necesita.

Fuente

2009-07-10 17:34:35

Se olvidó de seguir esto. Resulta que /usr/include no se puede incluir con /usr/include/linux en esta distribución en particular. size_t parece ser aniquilado por el segundo incluye.

Mis incluye ahora son simplemente /usr/include y funciona muy bien.

-I/usr/include -I/usr/include/ace -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0...

Sacando todos los incluye y jugando con ellos lo arregló.

Fuente

2009-07-18 17:30:23 EdH

size_t no puede ser encontrado por g ++ - 4.1 u otros en Ubuntu 8.1

Respuesta

Cuestiones relacionadas