# Can I use GLFW and GLEW together in the same code

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.

• "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. – Nicol Bolas Aug 13 '12 at 2:28
• @ 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 – Brendan Webster Aug 13 '12 at 7:00
• @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. – Nicol Bolas Aug 13 '12 at 8:44

GLFW can be used with GLEW:

http://www.glfw.org/faq.html#2_15

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")

• 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 – Brendan Webster Aug 13 '12 at 7:04
• "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. – Nicol Bolas Aug 13 '12 at 8:46
• @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? – David C. Bishop Aug 14 '12 at 8:18
• @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. – Nicol Bolas Aug 14 '12 at 8:54