Bug with dynamic GL loading

SDL Development
1

Was trying the old Mac binaries out, was
wondering why “testgl” just failed to run:

Couldn’t set GL mode: Couldn’t load GL function: glBegin

First I changed it, to report a more useful
error message than just “it failed, sir”:

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 other drivers seem to be loading GL with the context:

XVisualInfo X11_GL_GetVisual(_THIS)
…
/ load the gl driver from a default path /
if ( ! this->gl_config.driver_loaded ) {
/ no driver has been loaded, use default (ourselves) */
if ( X11_GL_LoadLibrary(this, NULL) < 0 ) {
return NULL;
}
}

int WIN_GL_SetupWindow(_THIS)
…
/* load the gl driver from a default path /
if ( ! this->gl_config.driver_loaded ) {
/ no driver has been loaded, use default (ourselves) */
if ( WIN_GL_LoadLibrary(this, NULL) < 0 ) {
return(-1);
}
}

Should I add a similar call to the Macintosh driver ?
(I couldn’t see where it unloaded the library, though)

int QZ_SetupOpenGL (_THIS, int bpp, Uint32 flags) {
…
/* Convince SDL that the GL “driver” is loaded */
this->gl_config.driver_loaded = 1;

This looks like a hack, should probably use above code.

I just inserted a call to "SDL_GL_LoadLibrary(NULL);"
before the #include “SDL_glfuncs.h”, and it worked.

Here’s the quick-and-dirty patch:
http://www.algonet.se/~afb/SDL-1.2.9-dyngl.patch

This probably leaks a lib handle, so it should most likely
be handled better. But at least it works properly, with GL ?

The Quartz version seems to be “cheating” here anyway, as it
loads and unloads the CFBundle for every GL_GetProcAddress ?

–anders

2

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. :slight_smile:

–ryan.

3

Ryan C. Gordon wrote:

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.

Right. I hadn’t read the SDL docs properly, so the patch was wrong in
that regard…
(The error reporting would still be nice to have, so just ignore that
last line)

i.e. http://www.algonet.se/~afb/libsdl/SDL-1.2.9-dyngl.patch [corrected]

SDL_GL_LoadLibrary (which seems to lack a public
"SDL_GL_UnloadLibrary", by the way?)
should be done by the user before setting the video mode up. Mac driver
should change.

But actually I did not use SDL_GL_GetProcAddress, the library did that
all by itself :slight_smile:

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.

Well, I don’t want to load OpenGL by default - but only dynamically
so I’m using function pointers for everything including glBegin.

But I’m doing that outside of SDL, just as do my GL capabilities tests ?
Plus some other utility functions, the sub-library is called
"BlitKernel":

See http://sourceforge.net/projects/spriteworldx/

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.

I’ll just copy and paste that snippet to the Mac driver, as well.
And also cleaned up the Quartz hacks, to use LoadLibrary instead.

Is there a reason why the “dyngl” test had some hardcoded old paths,
instead of just defaulting to NULL if user didn’t give any specific ?

These are the changes to the Mac OS X / Mac OS 9 drivers:

Move the CFBundle support to SDL_loadso, instead of GL:
http://www.algonet.se/~afb/libsdl/SDL-1.2.9-loadso.patch
Note 1: also added a small “testload” program (generic)
Note 2: only works with bundles/frameworks, not .dylib

Use the now-working loadso, for the Cocoa driver:
http://www.algonet.se/~afb/libsdl/SDL-1.2.9-quartzgl.patch

Load the Carbon GL library, if the user didn’t:
http://www.algonet.se/~afb/libsdl/SDL-1.2.9-macgl.patch

Adding more hardcoded paths to the “dyngl” test program:
http://www.algonet.se/~afb/libsdl/SDL-1.2.9-testgl.patch

And we can probably take the default -framework OpenGL out,
from the Mac OS X builds… Maybe also remove the bundled
Mac OS 9 “OpenGL SDK” files, as they look old ? (not 1.2)

i.e.
CWprojects/Support/Carbon/Include/agl.h
CWprojects/Support/Carbon/Include/GL/gl.h
CWprojects/Support/Carbon/Include/GL/glu.h
CWprojects/Support/Carbon/Lib/PPC/MemoryStub Unsupported!
CWprojects/Support/Carbon/Lib/PPC/OpenGLLibraryStub
CWprojects/Support/Carbon/Lib/PPC/OpenGLUtilityStub
CWprojects/Support/MacOS/Include/agl.h
CWprojects/Support/MacOS/Include/GL/gl.h
CWprojects/Support/MacOS/Include/GL/glu.h
CWprojects/Support/MacOS/Lib/PPC/OpenGLLibraryStub
CWprojects/Support/MacOS/Lib/PPC/OpenGLMemoryStub
CWprojects/Support/MacOS/Lib/PPC/OpenGLUtilityStub

The latest one is available from Apple, if it should it be required.
ftp://ftp.apple.com/developer/opengl/SDK/OpenGL_SDK_1.2_Core.img.bin

I don’t think OpenGL files needs to be bundled with the SDL download ?

–anders

4

i.e. http://www.algonet.se/~afb/libsdl/SDL-1.2.9-dyngl.patch [corrected]

This is in CVS, thanks!

But actually I did not use SDL_GL_GetProcAddress, the library did that
all by itself :slight_smile:

Yeah, I’m just saying some absolutely must do it even if the user didn’t.

Adding more hardcoded paths to the “dyngl” test program:
http://www.algonet.se/~afb/libsdl/SDL-1.2.9-testgl.patch

I’m inclined to think we should just explicitly say “NULL will try to
pick a reasonable default for the given platform” since it shouldn’t
break any existing programs and it removes the need for those nasty
#ifdefs in every SDL program.

–ryan.

5

Ryan C. Gordon wrote:

Adding more hardcoded paths to the “dyngl” test program:
http://www.algonet.se/~afb/libsdl/SDL-1.2.9-testgl.patch

I’m inclined to think we should just explicitly say “NULL will try to
pick a reasonable default for the given platform” since it shouldn’t
break any existing programs and it removes the need for those nasty
#ifdefs in every SDL program.

That would be much better, yes. You could even make it a constant:

#define SDL_DEFAULT_GL_LIBRARY_PATH NULL

–anders

6

I’m inclined to think we should just explicitly say “NULL will try to
pick a reasonable default for the given platform” since it shouldn’t
break any existing programs and it removes the need for those nasty
#ifdefs in every SDL program.

That would be much better, yes. You could even make it a constant:

#define SDL_DEFAULT_GL_LIBRARY_PATH NULL

Sounds good to me…

-Sam Lantinga, Software Engineer, Blizzard Entertainment