2011-01-03 6 views
0

Ich muss Komponententests mit Cmockery zu einer vorhandenen Build-Umgebung hinzufügen, die als handgefertigte Makefile verwendet. Also muss ich herausfinden, wie man cmservic.c (ohne Automake) baut.Wie arbeite ich um den GCC "Fehler: Umwandlung von" SourceLocation * "zu" int "verliert Genauigkeit" Fehler beim Übersetzen von cmservicy.c?

Wenn ich laufen:

g++ -DHAVE_CONFIG_H -DPIC -I ../cmockery-0.1.2 -I /usr/include/malloc -c ../cmockery-0.1.2/cmockery.c -o obj/cmockery.o 

ich eine lange Liste von Fehlern wie diese:

../cmockery-0.1.2/cmockery.c: In function ‘void initialize_source_location(SourceLocation*)’: 
../cmockery-0.1.2/cmockery.c:248: error: cast from ‘SourceLocation*’ to ‘int’ loses precision 

Hier sind Linien 247: 248 von cmockery.c:

static void initialize_source_location(SourceLocation * const location) { 
    assert_true(location); 

assert_true ist definiert in Zeile 154 von cmservice.h:

#define assert_true(c) _assert_true((int)(c), #c, __FILE__, __LINE__) 

Also das Problem (wie die Fehlerzustände) ist GCC nicht gefällt die Umwandlung von 'SourceLocation *' zu 'Int'.

I Cmockery mit ./configure und make (auf Linux und on Mac OS X wenn ich export CFLAGS=-I/usr/include/malloc zuerst), ohne Fehler bauen. Ich habe in der Befehlszeile versucht suchen, cmockery.c kompiliert, wenn ich make laufen (nach ./configure):

gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Isrc/google -I/usr/include/malloc -MT libcmockery_la-cmockery.lo -MD -MP -MF .deps/libcmockery_la-cmockery.Tpo -c src/cmockery.c -fno-common -DPIC -o .libs/libcmockery_la-cmockery.o 

... aber ich sehe keine Optionen, die diesen Fehler umgehen könnten.

In "error: cast from 'void*' to 'int' loses precision", ich sehe, ich könnte (int) in cmiclew.h zu (intptr_t) ändern. Und ich habe bestätigt, dass das funktioniert. Aber da ich mit ./configure und make Cmservice bauen kann, muss es eine Möglichkeit geben, es zu bauen, ohne die Quelle zu ändern.

+1

Nun, es lässt Sie wissen, dass Zeiger (64 heutzutage) größer sind als Ints (vielleicht 32). Ich frage mich, ob eine Doppelbesetzung oder etwas wie (int) (((lang lang) x) & 0x00000000ffffffff) es ausreichend betrügen würde. –

+1

Haben Sie versucht, 'gcc' anstelle von' g ++ 'zu verwenden? Die Verwendung von 'g ++' ändert gelegentlich einige Dinge in der Sprache. – thkala

+0

David, Ändern der Besetzung zu (intptr_t) funktioniert, aber ich sollte nicht die Cmservice-Quelle ändern müssen. –

Antwort

2

Mit gcc statt g++ auf meinem System schaltet sich, dass Fehler in eine Warnung auf meinem System (Mandriva Linux 2010.1 64-bit) und ermöglicht die Zusammenstellung vervollständigen:

. 
. 
. 
../cmockery-0.1.2/cmockery.c:248: warning: cast from pointer to integer of different size 
. 
. 
. 

ich das Bedürfnis, darauf zu hinweisen, Allerdings bin ich im Allgemeinen vorsichtig, wenn ich eine ganze Horde von Warnungen auf einer relativ allgemeinen Plattform sehe (Linux 64-bit/GCC und ich würde andere vermuten). Die Verwendung der -m32-Option zum Erzwingen der Kompilierung in einer 32-Bit-Objektdatei führt nicht zu Warnungen, daher könnte man annehmen, dass der verwendete Quellcode möglicherweise nicht 64-Bit-sauber ist. Dies geschieht unabhängig davon, ob Sie die Autotools verwenden oder nicht.

Ich weiß nicht, das Projekt in Frage, so könnte es sehr gut in Ordnung sein, aber auf jeden Fall mit Vorsicht verwenden ...

EDIT:

Nach this Antwort auf die Frage des OP zu der Mailingliste von Geschirr, der aktuelle Release ist zu diesem Zeitpunkt nicht 64-Bit sauber. Es scheint, dass die Fehler/Warnungen aus einem guten Grund da waren ...

+0

Cmservice (wie freigegeben) ist nicht 64-Bit sauber: http://groups.google.com/group/contessy/msg/278ef41d988f24e1?hl=de –

+0

@Daryl Spitzer: autsch ... – thkala

Verwandte Themen