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.
[/quote]
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.
http://www.opengl.org/registry/ABI relevance
Is http://www.opengl.org/registry/ABI still up to date? What confuses me is that:
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.
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.
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.
[quote name='ic0de' timestamp='1347928214' post='4981072']
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.
[/quote]
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.
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.
It's probably different with Linux because as far as I know ELF automatically exports all functions from a shared library.
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.[/quote]
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?
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
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?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement