I'm attaching a patch against 41c1305a, that adjusts how glew.c is generated so that it does the right thing depending on the GL_VERSION reported by the context.
One side effect is that glewGetExtension() makes a lot more GL calls (it iterates through all extension, calling glGetStringi for each, until it finds the one it is looking for).
Tested on Fedora 17 x86_64, glewinfo output is unchanged before/after the patch.
I observed issues on Windows with this patch, and reverted it at the last moment for the purpose of GLEW 1.10.0. (Argh!) Bumping this to the "1.9.2" category for a GLEW 1.10.1.
Nigel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-07-22
Can you post details about the issues? I may be able to take a look (no promises I'm afraid) later this week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In a nushell - glGetStringi hasn't been loaded yet when we're in the process of looking at all the extensions, before we go ahead and init based on the version and extensions. On Windows GLEW seemed to be trying to link glGetStringi from opengl32.dll - a deal breaker.
Nigel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How about the attached minimally invasive patch? (This is against 1.10.0's generated glew.c, since I'm on Windows and I haven't tried to regenerate glew, but it should be trivial to apply to the master sources.)
Basically, there are only two calls (as far as I can see) to glGetString(GL_EXTENSIONS). This replaces them with calls to _glewGetExtensions(), a static helper function. This manually attempts to retrieve glGetStringi(), therefore it should not interfere with the "normal" retrieval and it should not be sensitive to when it is run during the glew initialization process. If it can retrieve glGetStringi(), it concatenates each extension into a static array, space-separated, and returns a pointer to that array. This avoids any CRT dependencies. If glGetStringi() returns a null pointer, the whole function returns null (as the callsites check for).
On the other hand, if glGetStringi() cannot be retrieved, the helper falls back to the deprecated call to glGetString(GL_EXTENSIONS).
On my machine, this returns identical strings (including the final space) for both the new-style and old-style codepaths for the compatibility profile (only the new-style works for core, of course, and it is the same except it lacks GL_ARB_compatibility), so the rest of glew should be oblivious as to which path was taken.
The only squirrelly bit is choosing the size of the static array. My machine (GTX 680, latest drivers) returns a string about 7000 chars long, so I chose 16 KB - this is hopefully plenty for all machines but not unnecessarily bloated.
Sorry for the delay. I'm not able to reproduce the problem (or I just don't understand it properly - I don't develop a lot under windows): I've copied the generated glew.{c,h}, glewinfo.c sources to a windows machine and built glew (shared/static), glewinfo using the vc10 project there. It compiles and links without problem. I've then run glewinfo under apitrace (trace attached) and verified it only makes calls to glGetStringi - I'm attaching the trace file.
Could you give me some additional hints on how to reproduce the problem? Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-10-13
I had an issue related to this bug (with an OpenGL 4.4 context):
The GL_EXTENSIONS causes an GL_INVALID_ENUM which is not handled by GLEW. Instead, I caught it at a different point in my code where I checked for a previous GL function's success. So independent of this error, it would be a good idea that GLEW clears all errors it may have produced by calling glGetError() once after initialization.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Duplicate of Bug 2927731: Calling glGetString(GL_EXTENSION) even in Core/FC context
Closing.
Closing as duplicate.
Re-opening, since there is a patch attached.
Will consider for GLEW 1.9.1.
I'm attaching a patch against 41c1305a, that adjusts how glew.c is generated so that it does the right thing depending on the GL_VERSION reported by the context.
One side effect is that glewGetExtension() makes a lot more GL calls (it iterates through all extension, calling glGetStringi for each, until it finds the one it is looking for).
Tested on Fedora 17 x86_64, glewinfo output is unchanged before/after the patch.
Thanks for the patch! Appreciated.
Patch applied to git TOT.
GLEW 1.10.0 coming soon.
Thanks for the patch!
I observed issues on Windows with this patch, and reverted it at the last moment for the purpose of GLEW 1.10.0. (Argh!) Bumping this to the "1.9.2" category for a GLEW 1.10.1.
Can you post details about the issues? I may be able to take a look (no promises I'm afraid) later this week.
In a nushell - glGetStringi hasn't been loaded yet when we're in the process of looking at all the extensions, before we go ahead and init based on the version and extensions. On Windows GLEW seemed to be trying to link glGetStringi from opengl32.dll - a deal breaker.
Hmm, weird, the split of glew_init_gl.c into two parts was supposed to avoid that, guess I missed a spot - I'll see if I can find it.
I'm thinking of revisiting this in September for the purpose of a 1.10 bugfix release. If you can spare any cycles, I'd like to put this one to rest.
How about the attached minimally invasive patch? (This is against 1.10.0's generated glew.c, since I'm on Windows and I haven't tried to regenerate glew, but it should be trivial to apply to the master sources.)
Basically, there are only two calls (as far as I can see) to glGetString(GL_EXTENSIONS). This replaces them with calls to _glewGetExtensions(), a static helper function. This manually attempts to retrieve glGetStringi(), therefore it should not interfere with the "normal" retrieval and it should not be sensitive to when it is run during the glew initialization process. If it can retrieve glGetStringi(), it concatenates each extension into a static array, space-separated, and returns a pointer to that array. This avoids any CRT dependencies. If glGetStringi() returns a null pointer, the whole function returns null (as the callsites check for).
On the other hand, if glGetStringi() cannot be retrieved, the helper falls back to the deprecated call to glGetString(GL_EXTENSIONS).
On my machine, this returns identical strings (including the final space) for both the new-style and old-style codepaths for the compatibility profile (only the new-style works for core, of course, and it is the same except it lacks GL_ARB_compatibility), so the rest of glew should be oblivious as to which path was taken.
The only squirrelly bit is choosing the size of the static array. My machine (GTX 680, latest drivers) returns a string about 7000 chars long, so I chose 16 KB - this is hopefully plenty for all machines but not unnecessarily bloated.
Just tried the patch from Nuwen and it seems to work well. Not sure why this problem has required 5 years of deliberation without any official action.
Sorry for the delay. I'm not able to reproduce the problem (or I just don't understand it properly - I don't develop a lot under windows): I've copied the generated glew.{c,h}, glewinfo.c sources to a windows machine and built glew (shared/static), glewinfo using the vc10 project there. It compiles and links without problem. I've then run glewinfo under apitrace (trace attached) and verified it only makes calls to glGetStringi - I'm attaching the trace file.
Could you give me some additional hints on how to reproduce the problem? Thanks!
I had an issue related to this bug (with an OpenGL 4.4 context):
The GL_EXTENSIONS causes an GL_INVALID_ENUM which is not handled by GLEW. Instead, I caught it at a different point in my code where I checked for a previous GL function's success. So independent of this error, it would be a good idea that GLEW clears all errors it may have produced by calling glGetError() once after initialization.
Thank you.
This bug is 3 years old and now causing serious problems on OS X :( Why the push out to 1.11.0? I'm going to take a look at it.
I am also very confused why this hasn't been fixed yet.