`glXGetProcAddressARB' undeclared

hellihjb

vermutlich wurde deine glx.h bei der installation eines grafiktreibers mit ati-bloedsinn ueberschrieben.
deklarier's doch selbst:

#ifdef __cplusplus
extern "C" {
#endif

#ifndef GLX_ARB_get_proc_address
#define GLX_ARB_get_proc_address 1
/* Don't wrap this in GLX_GLXEXT_PROTOTYPES! */
extern void (*glXGetProcAddressARB(const GLubyte *procName))(void);
typedef __GLXextFuncPtr ( * PFNGLXGETPROCADDRESSARBPROC) (const GLubyte *procName);
#endif

#ifdef __cplusplus
}
#endif

erin

Ati wohl nicht, aber nVidia könnte zutreffen.

Nur am Rande: Die ganze GL-Kiste scheint auf meinem Rechner sowieso ein Chaos zu sein. Ich versuchte, Tuxracer zu compilieren, aber configure war mit der glx.h-Version nicht zufrieden (zu alt !?). Daraufhin habe ich mal den wirklich alten Header von SuSE 7.2 (!) rüberkopiert, und nun lief configure durch. Dafür machte make nicht mehr mit (endlose Probleme mit dem Quelltext). Schließlich habe ich das Tuxracer-Binary von SuSE 7.2 übernommen, und das läuft absolut sauber, auch die Hardware-Beschleunigung.

Ich gehe der Sache weiter nach, brauch' aber noch Zeit, um die von rapso vorgeschlagene Lektüre zu lesen. Melde mich wieder.

Reinhard

erin

hellihjb schrieb:

deklarier's doch selbst:

extern void (*glXGetProcAddressARB(const GLubyte *procName))(void);

Wörtlich genau so stehen die Deklarationen in meiner glx.h. Und der Header wird geladen. Ich hab mich überzeugt, indem ich irgendein #define hineingeschrieben und vom Programm ausgegeben habe (natürlich, nachdem die kritische Zeile auskommentiert wurde). Könnte es vielleicht ein Library-Problem sein? Ich habe zwar alle denkbaren -l-Angaben zu gcc versucht, auch diejenigen, die im Original-Makefile von Tuxracer stehen, aber ...

Reinhard

hellihjb

Könnte es vielleicht ein Library-Problem sein?

die meldung von oben ist ein compilerfehler - beim linker bist du noch gar nicht.
davon abgesehen benoetigt man nur die libGL.
gibt es irgendwelche anderen header (zb frameworks die von sich aus schon opengl-functionalitaet anbieten) in denen bereits "GLX_ARB_get_proc_address" definiert ist und es in glx.h gar nicht zur deklaration kommt?

erin

Nein, das Testprogramm oben ist der gesamte Code.
Der Code wurde per Copy & Paste aus den Tuxracer-Sourcen übernommen. Um ganz klare Verhältnisse zu schaffen, bin ich noch einmal in die Suse 7.3 reingegangen (anderer nVidia-Treiber) und habe das Testprogramm dort ebenfalls gestartet: derselbe Fehler.

Nun habe ich (unter Suse) Tuxracer aus den Sourcen neu compiliert und vorher den Quelltext so geändert, dass die fragliche Zeile auf jeden Fall aufgerufen wird. Das Programm wurde einwandfrei compiliert und lief sauber.

Ich wollte auch wissen, ob der Befehl überhaupt wichtig ist. Dazu bin ich erneut von jungfräulichen Sourcen ausgegangen und habe nach configure in config.h das Flag HAVE_GETPROC... auf 0 gesetzt. Wieder lief alles sauber durch, und auch die Hardwarebeschleunigung funktionierte.

Es hat also den Anschein, dass von den Procadressen nichts Wesentliches abhängt. Trotzdem bleibt die Frage: Warum funktioniert etwas im Tuxracer-Kontext, nicht aber, wenn man es isoliert untersuchen will?

hellihjb

Ich wollte auch wissen, ob der Befehl überhaupt wichtig ist. [...]
Es hat also den Anschein, dass von den Procadressen nichts Wesentliches abhängt.

ohne getprocaddress kommt man nicht an die opengl-extensions.

erin

Ich muss noch mal nachhaken, weil es in einem ganz anderen Zusammenhang wiederum zu einer Kollision mit glx.h kommt. Ich hab das Problem wieder in ein kleines Testprogramm gepackt:

#include <stdio.h>
#include <tcl.h>
#include <GL/gl.h>

typedef enum {
    False = 0, 
    True = 1
} bool_t;

bool_t have_money;

int main () {
  have_money = False;
  if ( have_money ) printf ("\nHabe Geld genug\n"); 
  else printf ("\nBin leider blank\n"); 
  return (0);
}

Die Typdefinition steht ebenfalls in Tuxracer und wird durchgehend benutzt. Wahrscheinlich will Jasmin Patry damit C und C++ unter einen Hut bringen. Nun gut, das Programm reagiert genau so wie man am Code ablesen kann. Die Header sind nur pro forma eingebunden.

Sobald ich zusätzlich <GL/glx.h> einbinde, gibt's Ärger. Mit gcc compiliert:

gcc -c main.c
main.c:5: error: Syntaxfehler before numeric constant

und mit g++ compiliert:

g++ -c main.c
main.c:5: error: Fehler beim Parsen before numeric constant
main.c:7: error: ISO C++ forbids declaration of `bool_t' with no type
main.c:9: error: 'bool_t' is used as a type, but is not defined as a type.
main.c: In function `int main()':
main.c:12: error: `event' undeclared (first use this function)

Bemerkenswert ist halt die Tatsache, dass der Compiler nur meckert, wenn er sich mit glx.h abgeben muss. Verwende ich aber andere Bezeichner als True und False, ist wieder alles ok. Ich kapier nichts mehr.

Reinhard

hellihjb

gcc-Version 3.4.6 20060404 (Red Hat 3.4.6-3):
dein beispiel-source kompiliert wie erwartet fehlerfrei mit gcc und g++

erin

Debian gcc 3.3

Ich hab's noch mal versucht und den Quelltext aus diesem Thread mit Copy-Paste übernommen. Sobald #include <glx.h> dazugesetzt wird, gibt es die genannten Fehlermeldungen.

Also muss ich mich nicht nur um den Library-Dschungel rund um OpenGL, sondern auch noch um den "richtigen" Compiler kümmern. Danke für Deine Hilfe, ich nehme erst mal eine Auszeit und mache in den Tuxracer-Sourcen mit unkritischeren Sachen weiter.

Reinhard

dv_

Das mit glXGetProcAddress ist leider ein echtes Problem. Manche Header deklarieren glXGetProcAddress, manche glXGetProcAddressARB. Die einzigen beiden Optionen sind wirklich nur,

glXGetProcAddressARB selber zu deklarieren
beim Buildskript rauszufinden, ob es glXGetProcAddress oderglXGetProcAddressARB gibt, und das existierende nehmen

GLEW macht ersteres AFAIK. Letzteres ist aber mit einem vernünftigen Buildsystem kein Problem..