###There are a couple of important things to note here:

1. AMD did not always implement ARB_debug_output. Technically, ARB_debug_output is an improved version of AMD's original extension: AMD_debug_output. Older AMD drivers lagged behind NV in adopting the ARB'ified version of AMD's own extension.

• Now here is where things get really funny: GL_KHR_debug is yet another improvement on the ARB extension. There are theoretically implementations of OpenGL that support neither AMD nor ARB's debug output but do support KHR_debug. At its core (no pun intended), however, the KHR extension re-uses the same function names, enums and constants (but without the ARB suffix).

2. This extension is generally only listed if you query the extension string while you are running in a debug context.

• More importantly, GLEW is rather stupid when it comes to querying extensions by name and uses glGetString (GL_EXTENSIONS), which is invalid in core contexts. The macros such as GLEW_ARB_debug_output reflect whether the extension is listed in the extensions string (which GLEW may not even be capable of querying if you are using a core context).

###I would suggest you initialize GLEW this way instead:

/**
 * Tells GLEW not to use the extension string.
 *
 *   Instead, it determines if an extension is supported by actually trying to load it.
**/
glewExperimental = GL_TRUE;
glewInit ();

if (glDebugMessageCallbackARB != NULL) {
  // Debug Output is supported, hooray!
}

By the way, the extension GL_KHR_debug has one other benefit that GL_ARB_debug_output does not. You can look for this extension by name (assuming you properly query the extension string) whether you have a debug context or not. A non-debug context that supports debug output is guaranteed to list this extension, whereas it may not list GL_ARB_debug_output.

###There are a couple of important things to note here:

1. AMD did not always implement ARB_debug_output. Technically, ARB_debug_output is an improved version of AMD's original extension: AMD_debug_output. Older AMD drivers lagged behind NV in adopting the ARB'ified version of AMD's own extension.

• Now here is where things get really funny: GL_KHR_debug is yet another improvement on the ARB extension. There are theoretically implementations of OpenGL that support neither AMD nor ARB's debug output but do support KHR_debug. At its core (no pun intended), however, the KHR extension re-uses the same function names, enums and constants (but without the ARB suffix).

2. This extension is generally only listed if you query the extension string while you are running in a debug context.

• More importantly, GLEW is rather stupid when it comes to querying extensions by name and uses glGetString (GL_EXTENSIONS), which is invalid in core contexts. The macros such as GLEW_ARB_debug_output reflect whether the extension is listed in the extensions string (which GLEW may not even be capable of querying if you are using a core context).

###I would suggest you initialize GLEW this way instead:

/**
 * Tells GLEW not to use the extension string.
 *
 *   Instead, it determines if an extension is supported by actually trying to load it.
**/
glewExperimental = GL_TRUE;
glewInit ();

if (glDebugMessageCallbackARB != NULL) {
  // Debug Output is supported, hooray!
}

By the way, the extension GL_KHR_debug has one other benefit that GL_ARB_debug_output does not. You can look for this extension by name (assuming you properly query the extension string) whether you have a debug context or not. A non-debug context created by an implementation of OpenGL that supports debug output is guaranteed to list this extension, whereas it may not list GL_ARB_debug_output.