[SDL] Bug with dynamic GL loading

Ryan C. Gordon icculus at clutteredmind.org
Wed Sep 7 22:20:00 PDT 2005

> Couldn't set GL mode: Couldn't load GL function glBegin: No GL driver 
> has been loaded
> Ah, so that explains it then... No library handle.
> Wonder if that's a (Classic) Mac-specific little bug ?
> The Quartz version seems to be "cheating" here anyway, as it
> loads and unloads the CFBundle for every GL_GetProcAddress ?

Lots of rambling follows:

The docs say you need to call SDL_GL_LoadLibrary() before using 
SDL_GL_GetProcAddress(), since you may want to load something other than 
the system default GL...although really this is a Linux thing mostly, 
and even there it's a relic from the Mesa/3Dfx/UtahGLX/DRI/Nvidia days. 
Most systems, including modern Linux, want to load one library from one 
central place and it's the user, not the app, to blame if the wrong 
driver is installed there.

This is also why you can get away with passing a NULL to 
SDL_GL_LoadLibrary on MacOS X and other platforms, even though this is 
undocumented behaviour: those platforms don't care WHAT you request, 
since they'll ignore it anyhow.

That being said, the reason some platforms will do the loading for you 
is because, increasingly, they need standard GL entry points to do some 
common things...setting up the GL context used to be entirely 
glX/AGL/wgl/etc calls that were outside the GL proper, but that's less 
true now.

I don't know if your patch is correct in this case, but we should 
probably implicitly force a library load if the user hasn't done it 
already when SDL_SetVideoMode() is called with SDL_OPENGL...some 
platforms already do this, as you've seen.

In the meantime, we should fix that test program, too.  :)


More information about the SDL mailing list