12 replies to this topic

[santa01]

Is http://www.opengl.org/registry/ABI still up to date? What confuses me is that:

3.4. The libraries must export all OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture entry points statically.
It's possible (but unlikely) that additional ARB or vendor extensions will be mandated before the ABI is finalized. Applications should not expect to link statically against any entry points not specified here.

Does that mean any core functionality for OpenGL 2 and higher should be accessed by glXGetProcAddress() (Yet its defined in gl.h/glext.h)?

Also should I explicitly load anything with glXGetProcAddress() if all the prototypes are actually defined in glext.h? I am not talking about checks for extention support but about linking.

[ic0de]

Just make it easy for yourself and use GLEW http://glew.sourceforge.net/

[santa01]

Just make it easy for yourself and use GLEW http://glew.sourceforge.net/

glew is a nice helper library but still I want to figure out ho to do things properly without external dependencies.

[clb]

On Windows OpenGL 3, I have had to resort to using GLEW. On Mac OS X with OpenGL 3, I have not needed to query any entry points or use GLEW, just including the headers has worked for me so far (although I don't know if there are some extensions for which static linking doesn't exist on OS X). On Android and iOS with GLES 2, I haven't needed to query any entry points either, and just including the headers and linking statically has been enough.

[tanzanite7]

glew is a nice helper library but still I want to figure out ho to do things properly without external dependencies.

Then you have to do what glew does yourself - there is no other way.

Read http://www.opengl.or...tting_Functions for more information.

Edited by tanzanite7, 22 September 2012 - 12:19 PM.

[mhagain]

Just make it easy for yourself and use GLEW http://glew.sourceforge.net/

glew is a nice helper library but still I want to figure out ho to do things properly without external dependencies.

I wouldn't call GLEW an external dependency - since the number of entry points is so huge an extension loader is more of an essential tool.

Sure, if you want to know how it's done, then try it out for a few - up to, say, GL1.5 - then say "life's too short to load this crap by hand" and spend your time being productive instead.

[Chris_F]

Well, on Windows, OpenGL32.dll only exports OpenGL 1.x functions which makes it absolutely mandatory to use wglGetProcAddress if you want to use anything newer than 1.x.

It's probably different with Linux because as far as I know ELF automatically exports all functions from a shared library.

[santa01]

Then you have to do what glew does yourself - there is no other way.

Read http://www.opengl.or...tting_Functions for more information.

See, there is a point in clb's post:

On Mac OS X with OpenGL 3, I have not needed to query any entry points or use GLEW, just including the headers has worked for me so far (although I don't know if there are some extensions for which static linking doesn't exist on OS X). On Android and iOS with GLES 2, I haven't needed to query any entry points either, and just including the headers and linking statically has been enough.

The same approach works for GNU/Linux, hence the question: Also should I explicitly load anything with glXGetProcAddress() if all the prototypes are actually defined in glext.h and imlicit linkage suits my needs?

[santa01]

I wouldn't call GLEW an external dependency - since the number of entry points is so huge an extension loader is more of an essential tool.

Well lots of extentions have been adopted into OpenGL core and currently I am planning to use a couple of them only.

Sure, if you want to know how it's done, then try it out for a few - up to, say, GL1.5 - then say "life's too short to load this crap by hand" and spend your time being productive instead.

You live only once

[santa01]

On Windows OpenGL 3, I have had to resort to using GLEW.

Well, on Windows, OpenGL32.dll only exports OpenGL 1.x functions which makes it absolutely mandatory to use wglGetProcAddress if you want to use anything newer than 1.x.

Thats sounds bad. I have no Windows under my hand to check stuff but AFAIK default OpenGL32.dll should be owerwritten with `native' version on video driver installation so imlicit linkage without wglGetProcAddress should work, right?

[Brother Bob]

No, they should not. Windows provides opengl32.dll as a part of their OpenGL system and drivers provide a layer on top of this dll. Your program communicates with opengl32.dll, and opengl32.dll communicates with the driver.

[santa01]

Ok, so what we got:
- on UNIX based platforms OpenGL can be used as any other library: headers and dynamic librarires are shipped with vendor's video drives (nvidia or ati binary drivers) or with mesa (if we go free software way) so all we need to do is include gl.h, glext.h and link our application with libGL.so (still we need to check if our HW supports opengl extentions we need, glGetString(GL_EXTENSIONS) + search does the trick).
- on Windows platform we are stuck to wglGetProcAddress as OpenGL32.dll only exports OpenGL 1.x functions.
On the other hand all the troubles can be eliminated with glew library.
Correct me if something is wrong.

[tanzanite7]

Nope, i got nothing to add now.

PS. glew is not the only option (although i would recommend it over others because of it extensive coverage), the link i gave previously gives a few alternatives also (which may or may not be more suitable to you).