Using GL_ARB_vertex_buffer_object
Author
I''m trying to use the VBO extension on Linux. glxinfo says it''s supported, libGL exports the functions, but I cannot use it. When compiling with GL_GLEXT_PROTOTYPES defined, I get undefined references to all used functions (glBufferDataARB, glDeleteBuffersARB, glGenBuffersARB, glBindBufferARB) and glXGetProcAddressARB( (const GLubyte*)"glDeleteBuffersARB" ) returns a NULL pointer.
Does anyone have a (minimal) known working code example and compiling instructions I could use to test my setup?
Author
I am doing
and equivalent for the other functions mentioned. The compiler is happy about it (no type mismatches or anything), but the function pointers are just set to null. It works for some multitexturing functions as used in the NeHe tutorial about bumpmapping.
[edited by - Shadowdancer on March 21, 2004 4:41:44 PM]
PFNGLGLDELETEBUFFERSPROC glBufferDataARB = (PFNGLGLDELETEBUFFERSPROC)glXGetProcAddressARB( (const GLubyte*)"glDeleteBuffersARB" ); and equivalent for the other functions mentioned. The compiler is happy about it (no type mismatches or anything), but the function pointers are just set to null. It works for some multitexturing functions as used in the NeHe tutorial about bumpmapping.
[edited by - Shadowdancer on March 21, 2004 4:41:44 PM]
Rename the function-pointer variable (or place in a C++ namespace, etc.). The function-pointer variables should never have names like "glBegin" or "glBufferDataARB" or "glGetColorTableParameterivEXT"!
If that doesn''t fix it, you can probably get a hint what''s going wrong by using dlerror().
Author
APs, I don't really think it's a problem with the ponter variable's names since I get a null pointer regardless of whether I look at the variable or directly at the result of the call itself. Also, dlerror() returns an empty string.
EDIT: I'm starting to get what's going wrong. I'm using the ATI fglrx drivers which do provide a libGL.so but not the libGL.a which kinda screws the build. ldd shows me that the binary is not linked against libGL.so.
[edited by - Shadowdancer on March 23, 2004 8:46:56 AM]
EDIT: I'm starting to get what's going wrong. I'm using the ATI fglrx drivers which do provide a libGL.so but not the libGL.a which kinda screws the build. ldd shows me that the binary is not linked against libGL.so.
[edited by - Shadowdancer on March 23, 2004 8:46:56 AM]
I think you may be using glx incorrectly. You have to dlopen your libGL.so to get the functions, I believe. When I do opengl stuff on Linux, I don''t even link to libGL.so, I just get all the functions from the library with SDL, which just wraps dlsym (I believe glXGetProcAddress is implemented in the same way)
You can just link to libGL.so (-lGL) as a quick fix, but it''s usually better to grab all OpenGL functions (not just extensions) from the library after it''s been dlopened.
Never ever ever ever statically link in libGL.a!
You can just link to libGL.so (-lGL) as a quick fix, but it''s usually better to grab all OpenGL functions (not just extensions) from the library after it''s been dlopened.
Never ever ever ever statically link in libGL.a!
Author
This is solved, the problem was some bad link setup that caused the linker to always link statically.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
