Probleme mit Headerdatei xf86dgastr.h

[christophwth]

Hallo

ich kriege bein einem compile Vorgang
folgende Fehlermeldungen, die ich nicht so recht einordnen kann.

/usr/X11R6/include/X11/extensions/xf86dgastr.h:333: parse error before `KeyButMask'
/usr/X11R6/include/X11/extensions/xf86dgastr.h:333: warning: no semicolon at end of struct or union
/usr/X11R6/include/X11/extensions/xf86dgastr.h:333: warning: no semicolon at end of struct or union
/usr/X11R6/include/X11/extensions/xf86dgastr.h:339: parse error before `}'
/usr/X11R6/include/X11/extensions/xf86dgastr.h:339: warning: type defaults to `int' in declaration of
`u'
/usr/X11R6/include/X11/extensions/xf86dgastr.h:339: warning: data definition has no type or storage c
lass
/usr/X11R6/include/X11/extensions/xf86dgastr.h:340: parse error before `}'
/usr/X11R6/include/X11/extensions/xf86dgastr.h:340: warning: type defaults to `int' in declaration of
`dgaEvent'
/usr/X11R6/include/X11/extensions/xf86dgastr.h:340: warning: data definition has no type or storage c

Dies ist der Bereich für den die Fehlermeldungen angezeigt weden

<pre>

typedef struct {
union {
struct {
BYTE type;
BYTE detail;
CARD16 sequenceNumber B16;
} u;
struct {
CARD32 pad0 B32;
Time time B32;
INT16 dx B16;
INT16 dy B16;
INT16 screen B16;
KeyButMask state B16;
CARD32 pad1 B32;
CARD32 pad2 B32;
CARD32 pad3 B32;
CARD32 pad4 B32;
} event;
} u;
} dgaEvent;


#endif /* _XF86DGASTR_H_ */

</pre>

Wo ist da ein Fehler ich kann keinen entdecken.
Das ganze tritt auf bei einem build-test von xawdecode
Distri SuSE 7.0 :

Danke
Gruß
Christoph

[thommy]

Die Fehlermeldung ist irreführend, meist entpuppt sich eine fehlende Definition als Ursache. Also entweder ist BYTE oder CARD16...KeyButMask_state - also einer der verwendeten Typen - zum Zeitpunkt noch nicht definiert.

Thomas

[christophwth]

Hi
thommy
wie kann ich jetzt weiter vorgehen um die Ursache für die Fehlermeldung zu finden.
Ich habe mir noch die Headerdatei in der KeyButMask deklariet wurde angeschaut, aber
das bringt mich auch nicht weiter.

Nochmal Danke für Deine Hilfe.

Gruß
Christoph

[thommy]

Wir hatten erst gestern genau diesselbe Fehlermeldung, allerdings in C++.

Als Ursache entpuppte sich der wechselseitige Einbinden von Headerdateien. Also "bla1.h" includet (was für ein Wort ) "bla2.h" und "bla2.h" bindet ihrerseits "bla1.h" ein. Syntaktisch alles korrekt, aber der Compiler "verschluckt" sich.

Lösung war, in einer Datei das Einbinden zu streichen und stattdessen nur eine Vorwärtsdeklaration zu verwenden (wir verwendeten eine Klassendefinition, bei Dir sollte ein "extern ..." helfen). Der entfernte "include"-Aufruf muss dann allerdings in die zugehörige ".c"-Datei aufgenommen werden.

Ich hoffe, der Tipp nützt was...

Thomas

[christophwth]

Hallo


thommy Danke für Deine Tipps
Genau wie es von Dir beschrieben wurde, scheint es auch hier zu sein.
in der xf86dgastr.h wir wieder eine zweite Datei eingebunden.

Gibt ne Möglichkeit das Verschlucken zu umgehen? Der Compilier Aufruf im Makefile sieht so aus :
CFLAGS=-Wall -ffast-math -g -O2 -I. -I/usr/X11R6/include -DVERSION='"$(VERSION)"'
CXXFLAGS = $(CFLAGS) -I$(QTDIR)/include -I$(KDEDIR)/include
LDLIBS= -L/usr/X11R6/lib -lXaw3d -lXt -lSM -lICE -lXext -lXmu -lm\
-lX11 -lXxf86vm -lXxf86dga

So viel ich weiß wird in der neuen Version von xawtv die Datei auf die gleiche Weise includet wie in meiner.
So daß :
#ifdef HAVE_LIBXXF86DGA
# include <X11/extensions/xf86dga.h>
# include <X11/extensions/xf86dgastr.h>
#endif
#ifdef HAVE_LIBXXF86VM
# include <X11/extensions/xf86vmode.h>
# include <X11/extensions/xf86vmstr.h>
#endif

Dort unterscheiden sich allerdings die Mainfiles insofern, daß:
<pre>
#ifdef HAVE_LIBXXF86DGA
if (XF86DGAQueryExtension(dpy,&foo,&bar)) {
XF86DGAQueryDirectVideo(dpy,XDefaultScreen(dpy),&f lags);
if (flags & XF86DGADirectPresent) {
XF86DGAQueryVersion(dpy,&ma,&mi);
fprintf(stderr,"DGA: server=%d.%d, include=%d.%d\n",
ma,mi,XF86DGA_MAJOR_VERSION,XF86DGA_MINOR_VERSION) ;
if ((ma != XF86DGA_MAJOR_VERSION) &#0124;&#0124; (mi != XF86DGA_MINOR_VERSION))
fprintf(stderr,"DGA: version mismatch -- disabled\n");
else
have_dga = 1;
}
}
#endif
</pre>
im meinem File auftaucht, in dem Anderen aber nicht. Wenn ich das include &gt;/xf86dgastr.h &lt; ausklammere wird
XF86DGA_MAJOR_VERSION
nicht gefunden das ist in der Headerdatei
definiert. Dein Vorschlag ging jetz dahin, daß ich dort ein extern vorsetzten sollte?
Meine Frage dazu, wird dann nicht die Grundlegende Programmstuktur verändert ?
(im Bezug auf SpeicherBereich )
Oder bewirkt das nur das der Compilier
jetz weiß wo er suchen soll.

sorry, die vielen Fragen, aber das ist mein
1. compilieren über Makefile

Gruß
Christoph

[thommy]

Wenn der Compiler eine Variable, Struktur, Klasse... anlegen soll, muss er wissen, wie viel Speicherplatz zu reservieren ist. Das heißt, der Typ muss zum Zeitpunkt des Kompilierens bekannt sein.

Jetzt kommt es bei der modularen Programmieren (also Aufteilung der Quellen in mehrere Dateien) immer wieder dazu, dass ein Typ in mehreren Dateien benötigt wird. Solch ein Typ darf mehrfach deklariert (bekannt gegeben) aber nur genau einmal definiert (Speicherplatz angelegt) werden.

Durch ein vorangestelltes "extern" sagst Du dem Compiler, wie der Typ aufgebaut ist, somit ist er in der Lage sowohl Typprüfungen vorzunehmen als auch korrekte Strukuren auf dem Stack (Funktionswertübergabe) anzulegen. Der Compiler weiß aber gleichzeitig, dass er hier keinen Speicherplatz zu allokieren braucht, weil dies woanders ("extern") geschieht.

Jetzt zu Deinem eigentlichen Problem... Anhand der Listings ist es unmöglich eine Diagnose zu stellen, aber ich würde wie folgt vorgehen:

<ul>[*]Getrenntes Übersetzen der einzelnen Komponenten (eventuell per Hand "cc -c bla.c -I/Alle_notwendigen_Include_Pfade"); vielleicht entlarvt sich hier der Fehler</li>
[*]Ändern der Reihenfolge der Übersetzung (vor allem Dateien, die die "Problemheader" einbinden)</li>
[*]Streichen des Problemheaders in einer Datei und versuchen, alle nicht bekannten Typen per extern zu deklarieren. </li>
[*](mir sagen, um welches Paket es sich handelt -- ich lad's mir runter und versuche selbst mein Glück)</li>[/list]

Viel Glück
Thomas

[christophwth]

thommy
Ich bin noch nicht dazu gekommen das von Dir Erwähnte auszuprobieren.
Da ich im Moment mit der Schule so viel zu tun habe. Naja mal wieder ein Semester in dem ich mir viel vorgenommen habe
Die Adresse des Downloads habe ich auch nicht parat, aber ich könnte dir das Ganze per
Mail schicken.
Wenn also noch Interesse Deinerseits besteht, kurze Mitteilung im Forum machen.
Aber wie schon gesagt bresonders wichtig ist das im Moment für mich nicht, daß das Ding funktioniert. Ich habe sowieso keine Zeit zum Fernsehen.

Gruß
Christoph

[thommy]

Her mit dem Paket!

Thomas

[thommy]

Die Lösung des Problems fand sich binnen weniger Minuten. Sicherlich war etwas Glück dabei, aber das prinzipielle Vorgehen bei solchen Fehlern möchte ich kurz skizzieren.

Zunächst ließen sich die von Christoph geposteten Fehlermeldungen nachvollziehen (XFree86 Version 4). Da diese Version doch recht neu ist, liegt es nahe, die Übersetzung auf dem Vorgänger zu versuchen und ... siehe da... unter 3.3.6 schnurrte der Compiler locker durch.

Die logische Konsequenz ist die Suche nach den Header-Dateien, in denen sich die Schnittstellen geändert haben könnten. Und hier bietet sich die Suche nach unbekannten Symbolen an. Der Compiler scheiterte u.a. an XF86DGA_MAJOR_VERSION, also suchte ich die Datei, die das Symbol definiert:

<pre>
user@sonne> for i in $(find /usr/X11R6/include -name "*.h" 2>/dev/null); do grep XF86DGA_M $i && echo $i; done
#define XF86DGA_MAJOR_VERSION 1 /* current version numbers */
#define XF86DGA_MINOR_VERSION 1
/usr/X11R6/include/X11/extensions/xf86dgastr_3x.h
</pre>

Der Compiler bemängelte die Strukturen der Datei ".../xf86dgastr.h"; vergleicht man nun diese Datei mit obiger "../xf86dgastr_3x.h", so erkennt man die fast identische Struktur.

Damit ergibt sich die Lösung, in main.c die Einbindung von xf86dgastr.h durch xf86dgastr_3x.h zu ersetzen... Und schon funzt es...

Grüße
Thomas



[Dieser Beitrag wurde von thommy am 24. November 2000 editiert.]

[christophwth]

Hi

thommy

Das es so einfach wäre hätte ich nicht gedacht. Auf die von Dir erwähnte Headerdatei bin ich auch schon gestoßen. Aber ich dort habe nicht nach dem Symbol gesucht. Das wäre wohl auch der nächste logische Schritt geworden.
Aber da ich mit X-programmierung noch nicht so viel am Hut hatte. Habe ich erstmal versucht das Makefile zu verstehen ob dort auch die richtigen Aufrufe im Bezug auf Übergaben an den Compiler und Umgebungsvariablen, gemacht werden.

Noch mal ein ganz großes Danke für Deine schnelle Hilfe


Gruß
Christoph