Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#144 GLEW check for extensions fails

Nigel Stewart

I'm using GLEW 1.5.2 on Kubuntu 10.04 x64 with latest ATI 4870 10.8 proprietary drivers (fglrx).

GLEW_ARB_map_buffer_range returns false even though I know the extension is available. glxinfo reports it as available.
glewIsSupported("GL_ARB_map_buffer_range") returns false.

But glXGetProcAddress((const GLubyte *)"glMapBufferRange") returns a valid pointer.


  • Nigel Stewart
    Nigel Stewart

    Please try current release of GLEW (1.5.5) or encourage an Ubuntu/Kubuntu packager to backport for 10.4.

    If you can confirm this bug for GLEW 1.5.5, we'll take action for sure. But most likely it is already fixed.

  • This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

  • This bug is still around in GLEW and you can encounter it in many more cases. The problem is that GLEW assumes that glXGetProcAddress returns NULL when a function isn't around, but in GLX the return value of glXGetProcAddress is undefined (on WGL and others it is NULL). There was some reasoning behind it. Anyway the function loading code in Mesa behaves like this. Just try loading ' glFooBar',

    The only real way is for GLEW to check whether an extension is around before allowing to load the function.

  • Nigel Stewart
    Nigel Stewart


    The spec language:

    A return value of NULL indicates that the specified function does not exist for the implementation.

    A non-NULL return value for glXGetProcAddress does not guarantee that an extension function is actually supported at runtime. The client must also query glGetString(GL EXTENSIONS) or glXQueryExtensionsString to determine if an extension is supported by a particular context.

  • Years ago I encountered the same issue when people reported some Wine GL bugs to me. At that time I looked at in detail including at Mesa. The main reason for this behavior has to do with indirect rendering. In that case the client library submits a command buffer to the X-server and the X-server takes care of the rendering. The X-server may only support a subset of what the client library offers, so for that reason you can't rely on the return value.

    In case of Mesa, the issue there was something in their function dispatching code. I think it allowed calls to be registered after doing the GetProcAddress, but I don't fully remember.

    The issue I had in Wine is that I had to emulate wglGetProcAddress through glXGetProcAddress. Since wglGetProcAddress does return NULL, I had to make sure the extension required by the call was around or that the correct GL version was matched (in case a non-EXT / non-ARB call got loaded).

  • Nigel Stewart
    Nigel Stewart

    GLEW does check for the extension string before doing glXGetProcAddress: (Unless glewExperimental is true)

    Closing this again based on the discussion.

    CONST_CAST(GLEW_ARB_map_buffer_range) = _glewSearchExtension("GL_ARB_map_buffer_range", extStart, extEnd);
    if (glewExperimental || GLEW_ARB_map_buffer_range) CONST_CAST(GLEW_ARB_map_buffer_range) = !_glewInit_GL_ARB_map_buffer_range(GLEW_CONTEXT_ARG_VAR_INIT);



Cancel   Add attachments