c - header Problem

Der Compiler weiß nicht, was AG_Surface sein soll.

heinz schrieb:
> Das sollte doch eigentlich passen?

Nur wenn AG_Surface, AG_DataSource und DECLSPEC auch an der Stelle 
bekannt sind.

heinz schrieb:
> typedef int AG_DataSource;
> extern DECLSPEC AG_Surface *AG_ReadSurfaceFromBMP(AG_DataSource *);
>
> so läufts durch (für die Zeile)

Das ist keine Lösung, sondern ein Verdecken des Fehlers.

Wo wird AG_Surface deklariert?
Die betreffende Headerdatei ist vor Deiner Definition einzubinden.

heinz schrieb:
> Dumm ist
> nur das die wieder abhaengigkeiten hat.

Dann bindest Du die falsche Headerdatei ein; das Agar-Toolkit wird da 
irgendeine standardisierte Vorgehensweise haben, die möglicherweise auch 
mit der Installation des Toolkits zu tun haben, also z.B. bestimmte 
Symbole definieren, um Plattformabhängikeiten zu definieren etc.

Welche Sourceversion des Toolkits hast Du heruntergeladen?

[Nachtrag]
Hast Du Dir die "platform-specific notes" auf 
http://libagar.org/docs/index.html.en angesehen?

Wenn Du einen anderen C-Compiler als die dort angegebenen verwendest, 
wirst Du herausfinden müssen, wie Du compilerspezifische Anpassungen für 
Deinen Compiler anpassen musst.
[/Nachtrag]



Im übrigen ist es bei solchen Problemen immer wichtig, sich mit den 
Fehlermeldungen der Reihe nach zu beschäftigen. Willkürlich eine 
herauszupicken ist sinnlos, da es sich fast immer um Folgefehler 
handelt.

heinz schrieb:
> yeo, die notes hab ich gelesen. Die beziehen sich aber auf MS VC ich
> benutz Pelles. Ist schon klar dass daher die Probleme kommen.
>
> Ich will aber auch nicht im Source des Toolkit rumändern.

Darum geht es ja auch nicht, Du musst halt nur die Umgebungsbedingungen 
soweit anpassen, daß Du "Deinen" Compiler verwenden kannst.

Alternative: Nimm einen anderen Compiler. Die Express-Version des 
MS-Compilers ist kostenlos.

heinz schrieb:
> @andi
> Qt == C++
> bei Qt gefällt mir die Abhängigkeit (von Qt) nicht.

Bei jeder Bibliothek hast du eine Abhängigkeit von ebendieser 
Bibliothek.

> Ich such was
>  einfaches

Im Sinne von einfach zu verwenden oder im Sinne von wenig Gesamtumfang?

>  statisch linkbar

Auch Qt ist statisch linkbar, allerdings ist statisches Linken meist 
eher weniger sinnvoll.

>  zu C passt

C halte ich für eher weniger geeignet für GUI-Programmierung. Ich hatte 
mir mal Gtk angschaut und fand es grauenvoll zu programmieren. Für 
vernünftige GUIs ist objektorientierte Programmierung quasi 
Voraussetzung, und die läßt sich zwar auch in C machen, aber teils nur 
sehr umständlich.

>  und platform unabhängig ist

Qt gibt es für fast alle gängigen Plattformen.

> spiel zur Zeit mit iup rum.

Ist mir unbekannt.

heinz schrieb:
> Darim gehts schon. C != C
> Das ist nicht so portable wie viele meinen. Steig ich im auf MS werd ich
> automatisch incompatibel zu ANSI.

Dann nimm GCC. Den gibt's kostenlos und für so gut wie jede Plattform, 
auch für Windows (MinGW). Im Gegensatz zu Microsoft bemüht sich GCC um 
hohe Konformität, und das auch zu C-Normen, die weniger als 20 Jahre alt 
sind.

Eine mögliche Alternative zu Qt ist wxWidgets:
http://www.wxwidgets.org/

Weitere Alternativen sind hier aufgelistet:
http://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries

Mark Brandis schrieb:
> Eine mögliche Alternative zu Qt ist wxWidgets:

Das hilft jemandem nicht, der kein C++ einsetzen will.

Rufus Τ. Firefly schrieb:
> Mark Brandis schrieb:
>> Eine mögliche Alternative zu Qt ist wxWidgets:
>
> Das hilft jemandem nicht, der kein C++ einsetzen will.

Es scheint da was in Richtung eines C-bindings zu geben:
http://wxc.sourceforge.net/

Weiß aber nicht, ob das noch gepflegt wird bzw. schon vollständig 
umgesetzt ist.

Abgesehen davon, GUIs ohne OOP machen doch keinen rechten Spaß. Wenn man 
zum Beispiel an die Win32 API denkt... (schauder)

heinz schrieb:
> Zu der Qt Abhängigkeit - ich denk man soll GUI und das eigentliche
> Programm trennen.

Das kann man doch gut mit Qt machen.

> Das was ich bei Qt gesehen hab find ich grausam (nie Qt programmiert, nur ein
> paarmal reingeschaut). Da ist das Prigramm durchsetzt mit Qt abhaengigen
> Sachen.

Was hat denn das eine mit dem anderen zu tun? Qt besteht aus mehreren 
Bibliotheken, und eine davon ist die GUI-Bibliothek. Man kann mit Qt 
auch Programme ganz ohne GUI schreiben, die dann auch nicht an 
irgendwelche GUI-Komponenten von Qt linken müssen. Wenn also ein 
Programm durchgehend Qt-Abhängigkeiten hat, heißt das nicht, daß deshalb 
der GUI-Code nicht vom restlichen Programm getrennt wurde.

> Ich link gern statisch weils dann keine Abhängigkeiten gibt. Ist schon
> klar dass ich da manchmal Speicher verschwende, aber wo ist der Sinn
> wenn ich ein Prg. schreib geteilt in eine kleine Exe und ein paar DLLs
> wenn kein anders Prg auf diese DLLs zugreift (benötigt)?

Naja, unter Windows ist diese Sache nie zufriedenstellend gelöst worden.
Beim statischen Linken mußt du übrigens ggf. mit der  Lizenz aufpassen. 
Wenn du statisch an Bilbiotheken unter der LGPL linkst, gibt es 
Einschränkungen, die zu beachten sind.

heinz schrieb:
> Zu den Lizensproblemen - die entfallen wenn ich opensource schreib.

Nein, das tun sie eben nicht.

Es gibt verschiedenen 'open-source' lizenzen, die aber zueinander 
inkompatibel sind.