size_t non può essere trovato da g ++ - 4.1 o altri su Ubuntu 8.1

Questo è successo prima a me, ma non riesco a ricordare come l'ho risolto.size_t non può essere trovato da g ++ - 4.1 o altri su Ubuntu 8.1

Non riesco a compilare alcuni programmi qui su una nuova installazione di Ubuntu ... Qualcosa non funziona con le mie intestazioni.

Ho provato g ++ - 4.1 e 4.3 senza successo.

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

il file ...

#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 è sicuramente nel percorso, ed è stato scelto su. Ho verificato cambiando il nome del file e ottengo un errore mancante ...

Qualcuno ha qualche idea ...? Apprezzerei molto l'aiuto ...

fonte

2009-07-10 EdH

Inizia rimuovendo -I/usr/include/linux e -I/usr/include. L'aggiunta di directory di sistema per includere manualmente i percorsi non ha alcun effetto o interrompe le cose. Inoltre, rimuovere -frepo per una maggiore sicurezza.

fonte

2009-07-10 07:26:45

È difficile dire qual è il problema senza vedere la tua fonte completa. Il modo migliore per eseguire il debug di problemi come questo è usare il parametro "-E" di g ++ per produrre l'output del pre-processore, e poi guardarlo per capire cosa sta succedendo nel tuo include. Ecco cosa dice la pagina informativa g ++ su "-E":

-E Arresto dopo la fase di pre-elaborazione; non eseguire correttamente il compilatore. L'output è sotto forma di codice sorgente preelaborato, che è inviato all'output standard.

Inoltre, perché non includere solo sys/types.h nella parte superiore del file?

Addendum:

Sul mio sistema, ho creato un breve file chiamato foo.cc che contiene solo:

#include <time.h>

E poi ho eseguito:

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

Guardare questa uscita in modo molto dettagliato è v sono importanti. Ad esempio, ho imparato che /usr/include/bits/types.h ha un typedef per __time_t, e che /usr/include/types.h usa quindi typedef per dire "typedef __time_t time_t". Ma ci sono altre interessanti macro che circondano questa definizione. Presta particolare attenzione a cose come la macro "__BEGIN_NAMESPACE_STD" in /usr/include/time.h, che sul mio sistema sembra essere una definizione vuota. Ma, posso immaginare che alcuni altri sistemi possano avere un valore diverso per questa macro, forzando la definizione di time_t in qualche altro spazio dei nomi.

Leggere la pagina delle informazioni Cpp, sezione "9 Uscita preprocessore" che definisce il formato delle righe del file. Di particolare rilievo è la sezione:

Fonte nome del file e numero di riga informazione è veicolata da linee di forma

# lineNum FILENAME BANDIERE

E poi passa a descrivere "BANDIERE "che sono di interesse per questo livello di debugging.

fonte

2009-07-10 06:17:41 slacy

grazie ... Ho provato ad aggiungere sys/types.h e types.h senza alcun risultato. ma -E è sicuramente utile - un grep su quello per size_t e non riesco a trovarne uno typedef per questo .... hmm – EdH

Un'altra cosa da provare sarebbe quella di confrontare l'output di "gcc -E /tmp/foo.c "e" g ++ -E /tmp/foo.cc "Il primo invoca il compilatore C e il secondo il compilatore C++. (foo.c e foo.cc non dovrebbero avere altro che "#include ". – slacy

In genere, non si dovrebbero usare file C .h per C++. Mentre si può trovare un modo semplice per farla franca, e mentre un sacco di questo è stato permesso nelle precedenti versioni di g ++ e in altri compilatori, lo standard C++ definisce size_t di essere in cstddef (si veda la sezione 18.2/tabella 17). g ++ sta diventando solo più severo.

Rimuovere tutti i include percorsi che avete aggiunto al vostro comando (sono ridondanti), e aggiungere alla parte superiore del codice sorgente se non incluso:

#include <cstddef> 
using namespace std;

fonte

2009-07-10 06:57:27

Questo non è vero. Le intestazioni C sono consentite nelle unità di traduzione C++ e non è necessario nemmeno preoccuparsi di usare equivalenti C++ come cstddef. –

Per favore cita un riferimento sul perché pensate che gli equivalenti del C++ non siano necessari.Tutti questi sviluppatori di compilatori C++ perdono davvero il loro tempo? –

cstddef è proprio come stddef.h tranne che cstddef è nello std dei nomi. Gli equivalenti C++ sono più convenienti per evitare l'inquinamento dello spazio dei nomi, Questo è tutto –

Avete installato il pacchetto build-essential?

sudo apt-get install build-essential

fonte

2009-07-10 16:59:36 kalleh

Sì, ho avuto. ma sicuramente ne hai sicuramente bisogno. Grazie. – EdH

che dovrebbe essere in stddef.h o cstddef. types.h non è una libreria standard e credo che si riferisca ai tipi di cui il sistema operativo ha bisogno.

fonte

2009-07-10 17:34:35

Ho dimenticato di dare seguito a questo. Si scopre che /usr/include non può essere incluso con /usr/include/linux su questa particolare distribuzione. size_t sembra essere spazzato via dal secondo include.

I miei inclusi ora sono semplicemente /usr/include e funzionano benissimo.

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

Estrarre tutti gli include e giocare con loro risolto.

fonte

2009-07-18 17:30:23 EdH

size_t non può essere trovato da g ++ - 4.1 o altri su Ubuntu 8.1

risposta

Problemi correlati