XML-RPC C
-
-->
.\src\XmlRpcSocket.cpp(61) : error C2065: 'EAGAIN': nichtdeklarierter Bezeichner
.\src\XmlRpcSocket.cpp(61) : error C2065: 'EINTR': nichtdeklarierter Bezeichner
<--
wenn das die einzigen fehler sind:#define EINTR (WSABASEERR+4) #define EAGAIN (WSABASEERR+1002)
-
fummel-freak schrieb:
wieso muss es eigentlich ein C-programm sein? gerade auch im hinblick auf plattformunabhängigkeit gibt es bessere lösungen, die ganz nebenbei XML-RPC schon mitbringen.
Naja, weil ich nun mal die meiste Zeit in C++ programmiere, ich mich dort auch die meiste zeit nicht gerade in plattformen eingeschränkt sehe, da ich plattformübergreifende bibliotheken benutze, und ich mir dachte: Es gibt doch nicht gerade wenige Projekte, die in C/C++ umgesetzt werden, also gibt es doch auch sicher anwendbare Lösungen für dieses problem -- gibt es ja auch, nur recht halbherzig für windows wie mir scheint...
Welches wären denn z.B. solche Lösungen? Java ist denk ich ma kein Problem, ne?^^
socket-freak schrieb:
-->
.\src\XmlRpcSocket.cpp(61) : error C2065: 'EAGAIN': nichtdeklarierter Bezeichner
.\src\XmlRpcSocket.cpp(61) : error C2065: 'EINTR': nichtdeklarierter Bezeichner
<--
wenn das die einzigen fehler sind:#define EINTR (WSABASEERR+4) #define EAGAIN (WSABASEERR+1002)Dankööö, damit konnt ichs zumindest schon mal mit VS erstellen... *freu* *dank*
schritt 2 wär dann versuchen, es zu benutzen, und schritt 3 das ganze dann noch mal für MinGW kompilieren... will ja nicht ewig an disem ding hängen...für die fehlermeldungen mit MinGW weiß keiner ne lösung oder?
werd mich aber mal in den nächsten tagen damit beschäftigen, hab jetzt einen hoffnungsschimmer
-
piXelshooter schrieb:
Naja, weil ich nun mal die meiste Zeit in C++ programmiere, ich mich dort auch die meiste zeit nicht gerade in plattformen eingeschränkt sehe, da ich plattformübergreifende bibliotheken benutze...
plattformunabhängigkeit mit C++ programmen zu erreichen ist sehr aufwendig und im grunde genommen nur eine illusion. noch nicht mal einfache dinge wie 'cout' spielen da richtig mit (beim einen gehts so, beim anderen brauchste 'flush' oder 'endl', damit der text sofort erscheint). vieles ist einfach undefiniert oder unspezifiziert und lässt compiler- und library-herstellern zu viel spielraum.
piXelshooter schrieb:
Welches wären denn z.B. solche Lösungen? Java ist denk ich ma kein Problem, ne?^^
ja daran dachte ich (wollt's nur nicht so direkt erwähnen, weil sonst die ganzen flame warriors gleich wieder auf der matte stehen). eventuell wäre python noch was, da weiss ich aber nicht, ob XML-RCP integriert ist.
socket-freak schrieb:
für die fehlermeldungen mit MinGW weiß keiner ne lösung oder?
wenn's auch auf 'ner unix-box laufen soll, dann mach's nicht mit mingw, sondern nimm einen richtigen GCC unter unix (BSD in eine vmware-maschine rein und du hast 'ne prima unix-testumgebung). wer weiss, beim GCC unter unix geht der build vielleicht ohne fehler durch.
-
Vista! Versuch doch mal deine Anti-C++-Einstellung hier mal langsam im Forum einzustellen. Versuch mal lieber C++-Hilfe zu geben! Eine andere Sprache empfehlen kann jeder Idiot, anstatt wirklich DAS gestellte Problem zu lösen! Nur weil du kein C++ kannst, müssen die anderen nicht darunter leiden, nicht weiter zu kommen.
-
Artchi schrieb:
Versuch mal lieber C++-Hilfe zu geben!
[...]
Nur weil du kein C++ kannst...wie passt das zusammen?
Artchi schrieb:
müssen die anderen nicht darunter leiden, nicht weiter zu kommen.
entschuldige bitte, aber vielleicht ist dir entgangen, daß ich durchaus versucht habe, pixelshooter in seiner not zu helfen (die #defines und so).
-
piXelshooter schrieb:
Welches wären denn z.B. solche Lösungen? Java ist denk ich ma kein Problem, ne?^^
ja daran dachte ich (wollt's nur nicht so direkt erwähnen, weil sonst die ganzen flame warriors gleich wieder auf der matte stehen).
Naja, wenn es stimmt...
Hab mich jetzt nur leider schon ziehmlich an C++ und C++-Bibliotheken gewöhnt...socket-freak schrieb:
für die fehlermeldungen mit MinGW weiß keiner ne lösung oder?
wenn's auch auf 'ner unix-box laufen soll, dann mach's nicht mit mingw, sondern nimm einen richtigen GCC unter unix (BSD in eine vmware-maschine rein und du hast 'ne prima unix-testumgebung). wer weiss, beim GCC unter unix geht der build vielleicht ohne fehler durch.
:)[/quote]
Müsst ich dann mal bei gelegenheit ausprobieren, gehe ich aber stark von aus. Das Problem ist, ich arbeite eigentlich immer mit GCC bzw. der MinGW portierung für windows. Und so viel ich weiß (was aber noch auf nen versuch ankommt...) kann ich dann nix mit VS-gebauten libs schaffen.
-
pixelshooter! Ist das makefile überhaupt für Windows ausgelegt? Wenn ich da rein schaue, kann ich keine Defines für Windows entdecken.
Laut XmlRpc++-Infos ist für Windows (lediglich) die MSVC-Projektdatei gedacht. Das würde erklären, warum es mit mingw nicht funktioniert. Die haben einfach das makefile nicht für Windows angepasst? (gehe ich jetzt mal von aus, kann ich mich auch täuschen)
Du könntest höchstens nochmal versuchen, die Defines wie -D_WINDOWS mit in das makefile zu schreiben. Schau mal dazu einfach in die XmlRpc.vcproj.
-
piXelshooter schrieb:
Naja, wenn es stimmt...
ja, stimmt. einen power-troll hatten wir schon^^
piXelshooter schrieb:
Hab mich jetzt nur leider schon ziehmlich an C++ und C++-Bibliotheken gewöhnt...
na, dann wird's mal zeit noch was anderes kennenzulernen. versteh' mich bitte nicht falsch, ich will dir C++ nicht madig machen, aber wenn man nur eine programmiersprache/umgebung/plattform etc. kennt, dann kann man vielleicht nicht so ganz optimal entscheiden, welches system für das konkrete problem am geeignetsten wäre. ich möchte mir nicht anmaßen der absolute checker zu sein, aber imho scheint deine vorgehensweise (auf-jeden-fall-mit-C++, platform-independent, XML-RPC) ein ziemlich dorniger weg zu sein.
-
könig drosselbart schrieb:
piXelshooter schrieb:
Naja, wenn es stimmt...
ja, stimmt. einen power-troll hatten wir schon^^
piXelshooter schrieb:
Hab mich jetzt nur leider schon ziehmlich an C++ und C++-Bibliotheken gewöhnt...
na, dann wird's mal zeit noch was anderes kennenzulernen. versteh' mich bitte nicht falsch, ich will dir C++ nicht madig machen, aber wenn man nur eine programmiersprache/umgebung/plattform etc. kennt, dann kann man vielleicht nicht so ganz optimal entscheiden, welches system für das konkrete problem am geeignetsten wäre. ich möchte mir nicht anmaßen der absolute checker zu sein, aber imho scheint deine vorgehensweise (auf-jeden-fall-mit-C++, platform-independent, XML-RPC) ein ziemlich dorniger weg zu sein.
werd mich ma umschauen... Schritt 2 ist jetzt sowieso erst ma die DB ans rennen zu kriegen...
Artchi schrieb:
pixelshooter! Ist das makefile überhaupt für Windows ausgelegt? Wenn ich da rein schaue, kann ich keine Defines für Windows entdecken.
Laut XmlRpc++-Infos ist für Windows (lediglich) die MSVC-Projektdatei gedacht. Das würde erklären, warum es mit mingw nicht funktioniert. Die haben einfach das makefile nicht für Windows angepasst? (gehe ich jetzt mal von aus, kann ich mich auch täuschen)
gehe ich nicht von aus, dass das makefile für C++ geeignet ist...
Du könntest höchstens nochmal versuchen, die Defines wie -D_WINDOWS mit in das makefile zu schreiben. Schau mal dazu einfach in die XmlRpc.vcproj.[/quote]
hm, kenn mich mit sowas nicht wirklich aus, von daher dürfte mir das etwas schwer fallen, aber: ICH SCHAFF DAS ;)^^
-
piXelshooter schrieb:
ICH SCHAFF DAS ;)^^
das ist die richtige einstellung --> niemals aufgeben
-
Sorry wegen der späten Antwort, aber die Weihnachtszeit ist für den PC etwas ungünstig.
piXelshooter schrieb:
Visual C++ schrieb:
------ Erstellen gestartet: Projekt: xmlrpc, Konfiguration: Debug Win32 ------
Kompilieren...
XmlRpcSocket.cpp
.\src\XmlRpcSocket.cpp(61) : error C2065: 'EAGAIN': nichtdeklarierter Bezeichner
.\src\XmlRpcSocket.cpp(61) : error C2065: 'EINTR': nichtdeklarierter Bezeichner
Browseinformationsdatei wird erstellt...Das ist jetzt zwar schon gelöst, aber ich habe die Library vor 2-3 Jahren mit VC++ 2003 gebaut. Ich erinnere mich nicht daran, das es dort diesen Fehler gab.
piXelshooter schrieb:
MinGW schrieb:
g++ -g -Wall -Wstrict-prototypes -O2 -I./src -c -o src/XmlRpcClient.o src/XmlR
pcClient.cpp
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid for Ada
/C/ObjC but not for C++
g++ -g -Wall -Wstrict-prototypes -O2 -I./src -c -o src/XmlRpcDispatch.o src/Xm
lRpcDispatch.cpp
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid for Ada
/C/ObjC but not for C++
src/XmlRpcDispatch.cpp: In member functionvoid XmlRpc::XmlRpcDispatch::work(do uble)': src/XmlRpcDispatch.cpp:85: error:fd_set' undeclared (first use this function)
src/XmlRpcDispatch.cpp:85: error: (Each undeclared identifier is reported only o
nce for each function it appears in.)Ich habe es eben unter Linux mal schnell probiert. Wenn man -Wstrict-prototypes entfernt, dann meckert GCC 4.x nur noch den fehlenden virtuellen Destruktor zweier Interfaceklassen an, aber die Library wird gebaut und die Tests laufen.
In XmlRpcDispatch.cpp wird nur für "nicht Windows" <sys/times.h> includet. Dort wird <sys/select.h> nachgeladen, welches die FD_ Makros definiert. Du muss also für MingW noch <sys/times.h> laden. Checke mal, ob es das Makro __MINGW__ gibt.
#if defined(_WINDOWS) # include <winsock2.h> # define USE_FTIME # if defined(_MSC_VER) # define timeb _timeb # define ftime _ftime # endif # if defined(__MINGW__) # include <sys/time.h> # endif #else # include <sys/time.h> #endif // _WINDOWSAnsonsten frohes Fest und ggf. schon jetzt einen guten Rutsch an alle.