anonymous wrote on Monday, December 14, 2009:

I would like to use gl3.h instead of gl.h with glfw. I tried just going
through the sources and replacing the include declarations with gl3.h, and
compiled/installed just fine… but I get a segmentation fault in glClear() in
_glfwPlatformOpenWindow() in glfwOpenWindow of /usr/local/lib/

Should glClear just be available after the gl3.h include or is there something
more that needs to be done? Has anyone done this?

Is this possible, or am I just peeing up a rope?

dalfy wrote on Monday, December 14, 2009:

I guess you are using glfw2.6. If you want OpenGL 3 and later you need to use
the version coming from trunk. It is available in Subversion. It is soon to be
release candidate so I would say it is stable enough to be used.

anonymous wrote on Thursday, December 24, 2009:

I was using 2.7 Lite from the repository. I know it was opengl 3 support, my
problem was that I want only gl3 support via gl3.h. This is the only way you
can be sure your code is fully 3.2 Forward compliant.

I eventually got this to work by commenting out some opengl calls in glfw
openwindow code. This got it to compile on linux, after which I added my own
init that setup all of the opengl commands using the glfw getproc function.

This allowed me to see that GL_QUADS had infact been depreciated, along with
a few other things that weren’t GL3.2+.

I now have a small template program using my modified glfw 2.7 lite and gl3.h,
that uses no depreciated functionality. All GL3.2+ and GLSL1.50.

Sadly, I’ve tried to get it going on windows now, and after more random
hacking, the getproc function isn’t working. I think it may because I strait
up commented out the part of the glfwExtensionSupported that used the
glGetString function. Not sure if that function is used internally…

Meh, I guess my choices are to stop using glfw, or to go in and try modify the
source enough to work… it’s getting a bit tiring.

Seems to defeat the purpose of glfw… I’m not getting to work on my game… I’m
fixing cross-platform issues… Nevermind how cmake on windows is a pain…

*sigh* I suppose glfw just isn’t for gl3.h peoples…

I wouldn’t mind it’s current setup for GL3 forward compat profile setup, but
it doesn’t throw any errors if I try to use depreciated functionality… I just
end up with a black screen and no reason why.

anonymous wrote on Thursday, December 24, 2009:

Well, still messing about with it. Figured that since I knew my code was 3.2+
compliant from running on linux with gl3.h, I could just use plain ole glfw
2.7 lite on windows and it should work just fine. I still got the same problem
however, and it seems it’s because base opengl functions provided by windows
can’t be accessed by glfwgetProcAddress. So, I’m going to exclude those from
the windows compile. I’ll post back when I get it working. >.>

elmindreda wrote on Friday, December 25, 2009:

Yeah, we should really support gl3.h and right now we don’t. I’m not sure if
(the entire) GLFW 2.x can run the core profile, but if it can, it should be
trivial to add a macro to select the GL header used.

I’m very interested in your work on this.

anonymous wrote on Saturday, January 02, 2010:

Well, I was mainly showing my n00bness there.

Yes, for the most part, just adding a macro similar to the glu one works fine.
Doing that, and excluding the examples and test from cmake was all that is
needed for linux.

Under windows is another story ofcourse. Here, we also need to declare some
function pointer variables, and set those. I wasn’t sure where the best place
to put this all in glfw or I would have submitted a patch. These are the files
I’m using in my current project to get full OpenGL 3.2 functionality on

It would be nice if you could just define GLFW_GL3, which would include gl3.h
as it does in thise glfw.h, but would also provide the function pointers
needed for windows, and add the init function right after context generation.
(With a check to the opengl version for compliance I suppose.) However, I
can’t see a way of doing this without polluting the glfw.h with our function
pointer exports.


pompei2 wrote on Wednesday, April 14, 2010:


I see these changes are not in the trunk yet. Do you plan to integrate them
some time soon? OpenGl 3 is the future, there is already 4 out here… Not many
opensource libs support opengl3 yet, would be great if glfw was one of the

elmindreda wrote on Tuesday, April 20, 2010:

I’ve added a macro for including gl3.h to my tree, just working out a few
details and I’ll commit it.