Snow Leopard, GLUT & GLEW - glGenTextures MISSING

Hi there,

I have been coding a small OpenGL project using GLUT and GLEW, and everything used to work fine under Windows, Linux and Mac OS 10.5… until I decided to upgrade to Snow Leopard (10.6.3).
The symptoms ? A Segmentation fault, showing a KERN_INVALID_ADDRESS at 0x0000000000000000. The last part of the stack shows a call to GLUT-3.4.4…

Binary Images:
0x100000000 - 0x10000aff7 +glsl_template ??? (???) <D98EB6B9-AB89-4C15-739A-BC5CA3A8AA53> /Users/stratboy61/Documents/glsl_template/glsl_template
0x100014000 - 0x100060fe7 com.apple.glut 3.4.4 (GLUT-3.4.4) <78324374-C4AC-2358-3D61-55060E44FC38> /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT
0x1000e1000 - 0x100102fff libGLEW.1.5.3.dylib ??? (???) <3E18F9F4-9312-6098-0FFA-F07456082376> /usr/lib/libGLEW.1.5.3.dylib
0x100126000 - 0x100150fff +libGL.1.dylib 1.2.0 (compatibility 1.2.0) <8AF04902-EE6B-636F-62AC-4353F550CC2B> /usr/X11/lib/libGL.1.dylib
0x100169000 - 0x1001cdfef +libGLU.1.dylib 1.3.0 (compatibility 1.3.0) <5F85284F-5DA3-BE6F-AC87-E0EA13ECB4EC> /usr/X11/lib/libGLU.1.dylib
0x1001e2000 - 0x1001e8ff7 com.apple.agl 3.0.12 (AGL-3.0.12) <C8CBED46-DB62-3D5C-70BE-B6FD407223A8> /System/Library/Frameworks/AGL.framework/Versions/A/AGL
0x1001ef000 - 0x1001fcfe7 libXplugin.1.dylib ??? (???) <CD329331-3561-20AE-D166-5C87BAC83D37> /usr/lib/libXplugin.1.dylib
0x100206000 - 0x100212ff7 +libXext.6.dylib 11.0.0 (compatibility 11.0.0) <169004BC-1FA3-A19C-B818-DACC66423F67> /usr/X11/lib/libXext.6.dylib
0x100219000 - 0x10032aff7 +libX11.6.dylib 9.0.0 (compatibility 9.0.0) <1363DEB7-B718-202D-537F-B0769D6A329C> /usr/X11/lib/libX11.6.dylib
0x100350000 - 0x100353fef +libXdmcp.6.dylib 7.0.0 (compatibility 7.0.0) <EEC19E9E-A303-01DF-D05A-2EB65054242C> /usr/X11/lib/libXdmcp.6.dylib
0x100358000 - 0x100359ff7 +libXau.6.dylib 7.0.0 (compatibility 7.0.0) <BC858886-138B-D7D3-48CE-E9EFA56747E8> /usr/X11/lib/libXau.6.dylib
0x10073c000 - 0x100762fe7 GLRendererFloat ??? (???) <684EBDC4-63B4-BC55-60EF-0F6A7D666551> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat
0x112b59000 - 0x112ce6fe7 GLEngine ??? (???) <85971DA9-5140-A226-7898-21B2D6C6F7FE> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine
0x112d17000 - 0x113139ff7 libclh.dylib 3.1.1 C (3.1.1) <08830748-80A3-2928-BDC9-D5512BE2715C> /System/Library/Extensions/GeForceGLDriver.bundle/Contents/MacOS/libclh.dylib
0x200000000 - 0x2006c3fe7 com.apple.GeForceGLDriver 1.6.10 (6.1.0) <8946B71C-EA96-5AFA-B8B6-E9029EAF56CD> /System/Library/Extensions/GeForceGLDriver.bundle/Contents/MacOS/GeForceGLDriver
0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???) <B633F790-4DDB-53CD-7ACF-2A3682BCEA9F> /usr/lib/dyld

Now, when I compile, install GLEW 1.5.3 and run glewinfo, I am rather surprised to see that glGenTexturesEXT does not seem to be available :
./glewinfo | grep -i glgentexture
glGenTexturesEXT: MISSING

As a matter of fact, the Segmentation fault occurs when calling glGenTextures for the first time. And yes, I called glutinit and glewinit before
Also, glGenTextureEXT is not the only extension that is missing, they pretty much all are…

I just do not understand what’s going on… I know that my video card supports OpenGL 2.0 and glewinfo finds glGenTexturesEXT under Linux. As I already said it, everything used to work fine under Leopard ! I did not change the code… Could it be the latest Mac OSX OpenGL drivers ?
Does it mean that GLEW tries to bind with GLUT, and Snow Leopard has a problem with GLUT ?

Man, I would be so glad to have a short explanation of what’s going on here !
Thank you in advance,
StratBoy61

In general, in your code, when you need a specific function, you should check first the OpenGL version supported and uses the functions provided by the OpenGL version, if the feature is not supported by the OpenGL version, try to check for the extension and uses the functions provided by the extension.

Do it in this order because a core feature of OpenGL does not have to be exposed as an extension.

Let me try to clarify it:

In your example, you try to use glGenTexturesEXT() which is defined by extension GL_EXT_texture_object.

At the same time, this extension became a core feature in OpenGL version 1.1 and glGenTextures() was defined.

Here is the list of OpenGL versions and extensions exposed by Snow Leopard:
http://developer.apple.com/graphicsimaging/opengl/capabilities/

or Leopard:
http://developer.apple.com/graphicsimaging/opengl/capabilities/GLInfo_1058.html

You can see that extension GL_EXT_texture_object is not exposed but the OpenGL version is greater or equal to 1.1. So you can use glGenTextures() but not glGenTexturesEXT().

Another typical example on Mac is the support of 3D textures:
it is defined as a core feature in OpenGL 1.2 but the extension GL_EXT_texture3D is not exposed on Mac. So glTexImage3DEXT() is not defined but, because the OpenGL version is equal or greater than 1.2, glTexImage3D() is defined.

In my opinion if it was working for you before your upgrade, it was only luck.

Thank you for your answer.
There must have been a confusion, and I am responsible for it : I am not using glGenTexturesEXT in my code, but I indeed use glGenTextures.
As my project would crash, I searched for a way to find out what was going wrong, and I ended up looking up the string ‘glgentextures’ in the output of glewinfo… Thus, I assumed that if glGenTexturesEXT was not supported, it was somehow related to glGenTextures…

How can you explain that glewinfo shows a support for glGenTexturesEXT under Linux and not under Mac (on my macbook which has a triple boot) ? Is there a way to have under SnowLeopard, the same drivers/libraries that seem to exist and work under Linux ?

Did you forget to call glutCreateWindow() between glutInit() and glewInit()? glutCreateWindow() is the line that actually creates an OpenGL context and it is required to have an OpenGL context before calling glewInit().
ref: http://glew.sourceforge.net/basic.html

As I said before, an OpenGL driver does not have to expose an extension supporting a feature if this feature is core in the supported OpenGL version. It does not have to expose it but it can. Apple chose to not expose it on Mac, the graphics card vendor chose to expose it on Linux.

No, there is no way to have the same driver on Linux and Mac. Apple controls the delivery of the the driver through the Mac update. On Linux and Windows your are free to download the latest driver from the graphics card vendor website (except for laptops on Windows sometimes).

I am pretty sure that I called glutCreateWindow between glutInit() and glewinit(), but I do not have the source code handy so I cannot say for sure. I will double check later.

What about the following explanation : I am using GLEW as a way to call native functions in OpenGL, and among these functions, there is glGenTextures. As glewinfo says that glGenTextures is missing, I assume that a call to this function would point directly to a null pointer (which is the error I get) ? And maybe GLEW was able to retrieve the correct OpenGL capabilities under Leopard, and no longer under Snow Leopard…

This is where I am not sure though : what is being called when I call glGenTextures ? Is is the GLEW interface that, imho, points to null, or is it a function from the OpenGL package ? But if it were the GLEW function, I would not be the only one having such a problem…

The other thing --in my case, is that the glewInit() is called within a static library, while the glutInit() and glutCreateWindow are called from the main program…
I might create a small POC and check what happens. This way, I could even post the entire source code…

I don’t use glew so I cannot tell much.

Looking at the glew change log ( http://glew.sourceforge.net/log.html ), 1.5.2 [12-31-09] has a bug fix for SnowLeopard gl.h detection. Are you up-to-date?

Thank you overlay for your answer.
I ended up finding what was wrong, and it is thanks to your support. I started a new project from scratch, that took something like 30 lines of code, and made a call to glGenTextures in it. Well, guess what ? It did not work, and I had the same error. And for some reason, I decided to strip off a max of things from the makefile (I am not using XCode under Mac, but maybe I should do it now!).
So I started removing libraries, when came the idea to include the OpenGL framework, which had never been mentioned in the makefile before.
Guess what ? Everything worked.

I am not Mac savvy enough to understand what happened, but I guess that I was linking to a part of X11 OpenGL…
Below are the two versions of the link command of the Makefile ; the commented line makes the binary crash on execution, while the other works just fine :

[b]OBJS = main.o
CC = g++
DEBUG = -g
CFLAGS = -Wall -c $(DEBUG) -I/usr/include
#LFLAGS = -Wall $(DEBUG) -L/usr/lib -L/usr/X11/lib -framework GLUT -lGL -lGLU
LFLAGS = -Wall $(DEBUG) -L/usr/lib -framework GLUT -framework OpenGL

test_glew : $(OBJS)
$(CC) $(LFLAGS) $(OBJS) -o test_glew

main.o : main.cpp
$(CC) $(CFLAGS) main.cpp

clean:
rm -f *.o *~ test_glew[/b]

When I check the two executables, I can clearly see the difference between the one that works and the other that does not :

[b]otool -L test_glew
test_glew:
/System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)

otool -L test_glew (wrong version)
test_glew:
/System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (compatibility version 1.0.0, current version 1.0.0)
/usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current version 1.2.0)
/usr/X11/lib/libGLU.1.dylib (compatibility version 1.3.0, current version 1.3.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)[/b]

Well, I will just have to brush up how frameworks work under Mac… it can be helpful.
Thanks again for the help !

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.