Compile-Problem
-
Hallo miteinander,
Ich hoffe ich bin im richtigen Forum hiermit:
Für die Ogre3D Engine gibt es ein Java-Binding. Leider ist in dem Paket nur ein VC++ Project-File dabei um die entsprechende DLL für die JNI-Calls unter Win32 zu erzeugen. Da ich das ganze aber unter Linux betreiben möchte versuche ich im Moment ein Makefile zu erstellen, mit dem ich eine entsprechende shared-library bauen kann.
Das Makefile sieht bis jetzt so aus (bis jetzt wird nur versucht eine Datei zu kompilieren):
CC = cc CFLAGS = -c LD = cc LDFLAGS = -o DEBUG = INCLUDEDIR = -I/usr/include/stlport -I./ogre4j/code/native/ -I../ogrenew/OgreMain/include/ -I/usr/local/Java/include -I/usr/local/Java/include/linux SRCDIR = ./ogre4j/code/native/ org_ogre4j_Viewport.o : ${CC} ${CFLAGS} ${DEBUG} ${INCLUDEDIR} ${SRCDIR}org_ogre4j_Viewport.cpp
Beim Ausführen von make kommt dann folgender Fehler mit dem ich so überhaupt nix anfangen kann:
cc -c -I/usr/include/stlport -I./ogre4j/code/native/ -I../ogrenew/OgreMain/include/ -I/usr/local/Java/include -I/usr/local/Java/include/linux ./ogre4j/code/native/org_ogre4j_Viewport.cpp In file included from ../ogrenew/OgreMain/include/OgrePrerequisites.h:80, from ../ogrenew/OgreMain/include/Ogre.h:28, from ogre4j/code/native/Ogre4JRoot.h:23, from ogre4j/code/native/org_ogre4j_Viewport.cpp:20: ../ogrenew/OgreMain/include/OgreMemoryManager.h: In function `void* operator new(unsigned int)': ../ogrenew/OgreMain/include/OgreMemoryManager.h:409: error: declaration of ` void* operator new(unsigned int)' [B]throws different exceptions[/B] /usr/include/c++/3.3/new:82: error: than previous declaration `void* operator new(unsigned int) throw (std::bad_alloc)' ../ogrenew/OgreMain/include/OgreMemoryManager.h: In function `void* operator new [](unsigned int)': ../ogrenew/OgreMain/include/OgreMemoryManager.h:414: error: declaration of ` void* operator new [](unsigned int)' [B]throws different exceptions[/B] /usr/include/c++/3.3/new:83: error: than previous declaration `void* operator new [](unsigned int) throw (std::bad_alloc)' ../ogrenew/OgreMain/include/OgreMemoryManager.h: In function `void operator delete(void*)': ../ogrenew/OgreMain/include/OgreMemoryManager.h:419: error: declaration of ` void operator delete(void*)' [B]throws different exceptions[/B] /usr/include/c++/3.3/new:84: error: than previous declaration `void operator delete(void*) throw ()' ../ogrenew/OgreMain/include/OgreMemoryManager.h: In function `void operator delete [](void*)': ../ogrenew/OgreMain/include/OgreMemoryManager.h:424: error: declaration of ` void operator delete [](void*)' [B]throws different exceptions[/B] /usr/include/c++/3.3/new:85: error: than previous declaration `void operator delete [](void*) throw ()' ogre4j/code/native/org_ogre4j_Viewport.cpp:168:80: Warnung: Kein Newline am Dateiende make: *** [org_ogre4j_Viewport.o] Fehler 1
Irgendwas fehlt da noch oder ist falsch, der Fehler tritt innerhalb der eigentlich Ogre-Sourcen auf, die ich aber vorher schon erfolgreich kompilieren konnte.
Hat da jemand eine spontane Idee welche Compiler-Flags oder Include-Verzeichnisse ich vergessen haben könnte?
Oder fehlt mir da irgendwo noch ein grundsätzliches Verständnis von C++? Irgendwas kompletter Blödsinn in dem Makefile? Wenn ja wär es Klasse wenn da jemand ein paar Links parat hätte wo ich mich weiterbilden kann
Gruß, Schmelly
[edit]Nachtrag: ist es evtl. falsch gegen STLPort zu kompilieren? Beim eigentlichen Ogre Paket dürfte das auch nicht der Fall gewesen sein, da ich STLPort erst später nachinstalliert habe. Allerdings bekomme ich ohne STLPort den Fehler, dass die includes <hash_set> und <hash_map> nicht gefunden wurden
-
Hm, nach ein bisschen überlegen bin ich zu dem Schlusse gekommen, dass das kompilieren gegen STLPort nicht wirklich funktionieren kann und hab in einem Ogre-Header folgendes #define gefunden:
#ifdef EXT_HASH # include <ext/hash_map> # include <ext/hash_set> #else # include <hash_set> # include <hash_map> #endif
Wenn ich nun allerdings EXT_HASH als Compiler-Parameter mit übergebe bekomme ich als ersten neben zig anderen Fehlern diesen hier:
../ogrenew/OgreMain/include/OgreString.h:65: error: [b]ISO C++ forbids declaration of `operator()' with no type[/b]
Damit kann ich auch so gar nix anfangen
-
dem Compiler fehlte wohl noch das Flag -DGCC_3_1
jetzt scheint es erstmal zu funktionieren... sry für die Umstände
-
*soifz*
mittlerweile funktioniert schonmal "relativ" viel... jetzt bekomme ich aber beim kompilieren Probleme mit einer JNI-Funktion:
ogre4j/code/native/org_ogre4j_Animation.cpp: In function `_jstring* Java_org_ogre4j_Animation_getName(JNIEnv*, _jobject*)': ogre4j/code/native/org_ogre4j_Animation.cpp:27: error: no matching function for call to `JNIEnv_::NewStringUTF([B]const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&[/B])' /usr/local/Java/include/jni.h:1578: error: candidates are: _jstring* JNIEnv_::NewStringUTF([B]const char*[/B])
bei den fett-gedruckten Stellen erwartet der Compiler also einen
const char*
und nicht ein Monster vom Typ
const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&
Aber da das aus der Standardbibliothek kommt sollte das doch eigentlich funktionieren wenn es unter Windoof kompilierbar ist oder? Oder hab ich da evtl. noch was übersehen/vergessen? Jemand eine Idee?
Gruß, Schmelly
der mal wieder lange Zähne bekommt mit dem ganzen Typ-Salat bei C++
-
Ich habe keine Ahnung von JNI und was Windows damit zu tun hat, aber das Monster ist ein einfacher std::string, den man über stringVar.c_str() in einen const char* "umwandeln" kann.
-
Nun, erstmal hat der Fehler ja nix mit JNI zu tun
wie ganz oben geschrieben versuche ich unter Linux eine Bibliothek zu erstellen, für die es nur ein VC++ .dsp File gibt. Die Sourcen existieren also schon und sind nicht von mir.
Daher wundert es mich, dass an einer Stelle, an der Funktionen der Standardbibliothek benutzt werden, unter Linux mit dem GCC ein Fehler auftritt, unter Windows mit dem VC++ Compiler aber nicht.
Aber dein Tip funktioniert, danke sehr, leider hab ich mein einziges C++ Buch im Moment verliehen
Leider ist das jetzt etwas unschön, dass ich den bestehenden Sourcecode an einigen Stellen ändern muss...
Gruß, David