https://bugs.freedesktop.org/show_bug.cgi?id=109524
--- Comment #8 from Ilia Mirkin imirkin@alum.mit.edu --- Doing a little more digging, we enabled GL_ARB_shading_language_100 unconditionally in 2013:
commit 70966570f3e4275dc15b5a94c70698f6aef64150 Author: Ian Romanick ian.d.romanick@intel.com Date: Thu Jun 27 18:20:31 2013 -0700
mesa: GL_ARB_shading_language_100 is not optional
However it appears that wine code has something like
https://source.winehq.org/git/wine.git/blob/201d13a3c31131f204f89d61be37bf75...
3737 if (gl_info->supported[ARB_SHADING_LANGUAGE_100]) 3738 { 3739 const char *str = (const char *)gl_info->gl_ops.gl.p_glGetString(GL_SHADING_LANGUAGE_VERSION_ARB); 3740 unsigned int major, minor; 3741 3742 TRACE("GLSL version string: %s.\n", debugstr_a(str)); 3743 3744 /* The format of the GLSL version string is "major.minor[.release] [vendor info]". */ 3745 sscanf(str, "%u.%u", &major, &minor); 3746 gl_info->glsl_version = MAKEDWORD_VERSION(major, minor);
I think the debugstr_a(NULL) is giving problems, but if it's not, sscanf probably will.
I'm not 100% sure who's right here. Certainly the GL_ARB_shading_language_100 spec talks about GL_SHADING_LANGUAGE_VERSION_ARB not being available due to it not existing in early extension specs.
However the current behavior is a bit questionable on the mesa side. I don't know what the rationale was for always exposing the ext (as given, it's because one ought to check for ARB_vertex_program/etc, but that seems weak).