Windows DLL hell when using GLEW with GL and DLLs


this is not a GL specific question per se, I rather stumbled across this when using GL with glew. When refactoring some of my code I decided to put all of my OpenGL wrapping code (buffer classes, etc) in a DLL. Furthermore I put some other stuff in other DLLs (window creation for example, since I use more than one possibility).
Now I created a small test application, linked against DLL A and DLL B (both have GL code inside of them). I use glew. At first I called glew_init from inside DLL A, after window and context creation (also done in DLL A), which works fine until I call code from DLL B (for example creating a buffer). It crahses with a null pointer when calling gl functions, which should have been initialized by glew. When I call glew_init in BOTH DLLs, it works just fine, but that seems wrong to me :slight_smile:
Is there a way to call glew_init just once (and where do I have to do it, I know I need a current GL context for it), and all DLLs “see” the same function pointers? Or is this just not the way it works?

thanks for any insights

Are you using GLEW as a static library or #including glew.c? That will create a separate set of variables for each binary (DLL or EXE), which will need to be initialised by calling glew_init() from that same binary.

If you want GLEW to behave as you expect, you’ll need to build GLEW as a DLL and link against that (or the appropriate import library). That will put one copy of the variables inside the GLEW DLL itself, and glew_init() will initialise them. Ensure that GLEW_STATIC isn’t defined.

Hi, yes I use GLEW as a DLL and GLEW_STATIC is undefined. I wrote a small test program and it works as expected. There is one difference to my large codebase though: I load the DLLs at runtime using Boost::DLL in my large codebase, I am looking at that right now, problem might be there.

So I only found another answer to this problem on StackOverflow: c++ - Linking to OpenGL from a DLL: glew functions are null when running - Stack Overflow. Looks like it’s glew behaving as it should, or at least it’s known behaviour. Anyways, I created a workaround based on calling glewInit for every DLL using extended OpenGL, and it works for now.