I use the g++ compiler, which could be causing the main problem, but I'm using GLFW for window and input management, and I am using GLEW so that I can use OpenGL 3.x functionality. I loaded in models and then tried to make Vertex and Index buffers for the data, but it turned out that I kept getting segmentation faults in the program. I finally figured out that GLEW just wasn't working with GLFW included. Do they not work together?

Also I've done the context creation through GLFW so that may be another factor in the problem.

  • 3
    \$\begingroup\$ "I finally figured out that GLEW just wasn't working with GLFW included." Or you just have a bug in your code. But we certainly can't tell without seeing any of it. \$\endgroup\$ Aug 13, 2012 at 2:28
  • \$\begingroup\$ Either you just answered your own question, or you need to provide more info. \$\endgroup\$
    – Rivasa
    Aug 13, 2012 at 2:40
  • \$\begingroup\$ @ Nicol, I know there isn't a bug in my code because I've debuged it besides the parts I mentioned, I know it to be infact a problem with using GLEW and GLFW together. @The Elite Noob, I stated my problem, I wanted to know if they work together and if so, how? I also stated that I was using GLFW for my context creation and that I was using the G++ compiler \$\endgroup\$ Aug 13, 2012 at 7:00
  • 2
    \$\begingroup\$ @Brendan: The easiest way to not find a bug is to declare that the bug definitely isn't in some place. Also, I know for a fact that GLFW has no problems working with GLEW generally. Therefore, if you're encountering problems, odds are good that something in your code is doing the wrong thing. \$\endgroup\$ Aug 13, 2012 at 8:44

2 Answers 2


GLFW can be used with GLEW:


2.15 - Can I use GLEW with GLFW?

Yes, as long as you include the GLEW header before the GLFW one. The GLEW header defines all the necessary magic macros to make sure the gl.h that GLFW attempts to include doesn't interfere.


I have been encountering some problems too.

What I have found is if you don't specify the context version or use core profile it seems to load the latest version of OpenGL without issues.

The glew error might be because of it using the older glGetString(GL_EXTENSIONS)​ rather than glGetStringi. You might be able to work around it by using glewExperimental=true before calling glewInit(). See here.

Otherwise you can drop GLEW all together and use the official Kronos OpenGL extension header glcorearb.h (previously it was gl3.h). That won't load 3rd party extensions but it seems to work fine for what I have been doing (not sure if it's suitable for large projects or not it's only listed as a reference implementation).

Also make sure you have called glewInit(). You can check if an extension is enabled with:

if(glGenBuffers) {

Otherwise GLEW has its own way using glewIsSupported("GL_ARB_vertex_buffer_object")

  • \$\begingroup\$ I'm going to try taking out some of the GLFW context as you mentioned, and we'll see if it works, if not I'll probably just use the glcorearb.h like you also mentioned. I do know that I've tried using glewExperimental=true, and it doesn't work in my situation \$\endgroup\$ Aug 13, 2012 at 7:04
  • 3
    \$\begingroup\$ "That won't load 3rd party extensions" That won't load anything. It's just a header; it doesn't do the hard part: getting function pointers. \$\endgroup\$ Aug 13, 2012 at 8:46
  • \$\begingroup\$ @NicolBolas: Would be interested to know more. The extention functions all 'just work' for me on Linux when using glcorearb.h without glew or any actual extension loading. Possibly they have been setup by the OpenGL implementation itself when it's linked? If that's the case why do they need to be loaded them at all? \$\endgroup\$ Aug 14, 2012 at 8:18
  • \$\begingroup\$ @David: I assume you #define GLCOREARB_PROTOTYPES. That only works on Linux machines that expose OpenGL functions through regular .SO functions. The way that works for all platforms requires loading the function pointers dynamically. That's why tools like GLEW and the GL SDK exist. \$\endgroup\$ Aug 14, 2012 at 8:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .