2

I'm trying to use glDrawArraysInstancedBaseInstance but the linker complains that __glewDrawArraysInstancedBaseInstance is unresolved.

glew-1.9.0 is installed on the machine and as far as I can tell it should be linking it.

As temporary work around, I'm just fetching the function myself, which works. But it does not help me understand why glew does not appear to be working for that function.

And actually glew does not appear to be working for anything opengl 3.3+

To verify that the function should be available I use glfwExtensionSupported("GL_ARB_base_instance").

To be clear, this is the GLFW function, not GLEW's extension checker.

I'm using glfw to create my window and a 4.3 core profile context

My system:
NVidia gtx 550 ti, with latest drivers
Ubuntu 12.04

To compile this I'm using CMake for the make files and in CMakeLists.txt:
target_link_libraries(app GL GLU GLEW glfw)

tamato
  • 838
  • 7
  • 15
  • What compiler are you using and can you edit your question to include the full compiler command line invocation (something like `g++ foo.cpp ...`) – anthonyvd Jul 16 '13 at 15:28
  • 1
    Also, according to this error message, it looks like you're trying to call `glewDrawArraysInstancedBaseInstance` where you want `glDrawArraysInstancedBaseInstance` – anthonyvd Jul 16 '13 at 15:29
  • I'm calling `glDrawArraysInstancedBaseInstance` but the linker reports `__glewDrawArraysInstancedBaseInstance` – tamato Jul 16 '13 at 15:32
  • Do other extension functions work? – Christian Rau Jul 16 '13 at 15:35
  • All extensions for opengl 3.2 and below. – tamato Jul 16 '13 at 15:38
  • You might need to update your drivers and make sure they support OpenGL 3.3+ if all the 3.3+ extensions fail to work. – anthonyvd Jul 16 '13 at 15:43
  • The question states that I have the latest nvidia drivers, and that I'm capable of fetching the function my self. – tamato Jul 16 '13 at 15:47
  • Did you try to see if OpenGL 3.3 was supported with something like `if (GLEW_VERSION_3_3)`? Regardless, your drivers *should* support OpenGL 4.3 according to https://developer.nvidia.com/opengl-driver – anthonyvd Jul 16 '13 at 15:52
  • @pwny Yet that (old drivers) would result in a runtime error when calling those rather than a linker error anyway. Sounds much more like GLEW not supporting it at all (though 1.9.0 should of course). – Christian Rau Jul 16 '13 at 15:54
  • @ChristianRau I agree with you. I don't know how GLEW works internally but I'm pretty sure the OpenGL implementations don't rely on GLEW being present. That and the fact OP gets a linker error for a GLEW function when calling a GL function makes me think there's a `#define glDrawArraysInstancedBaseInstance __glewDrawArraysInstancedBaseInstance` or something similar somewhere in GLEW which would be weird if GLEW didn't support that function. – anthonyvd Jul 16 '13 at 15:58
  • @pwny I have tried `if (GLEW_VERSION_3_3)` and that is the first one that fails. I've looked through glew-1.9.0 in glew.c and `GL_ARB_base_instance` is supported. I just don't why its not working. – tamato Jul 16 '13 at 16:00
  • updated question to show how I'm verifying that the requested function is available. – tamato Jul 16 '13 at 16:05
  • I'm sorry but at this point I've exhausted what I can think of. GLEW 1.9.0 should support up to OpenGL 4.3, your drivers obviously support them if they're up to date and you can actually go and get (I assume that's what you did) a pointer to the actual function. At this point I'd file a bug in GLEW... – anthonyvd Jul 16 '13 at 16:07
  • @pwny Thank you, I'll do that. – tamato Jul 16 '13 at 16:23
  • @tamato: Have you considered... *not* using GLEW? This isn't 2008, where the only options are GLEW or GLee, you know. There are a [number of alternatives](http://www.opengl.org/wiki/OpenGL_Loading_Library), some of which actually *work* with higher OpenGL versions. – Nicol Bolas Jul 16 '13 at 18:33
  • @NicolBolas tbh I haven't really looked into them, but now I'm thinking about giving OpenGL Loader Gen a go. – tamato Jul 16 '13 at 19:23

1 Answers1

1

It turns out to be that when installing glew-1.9.0, it was being installed to /usr/lib64 and this was only one of the two problems that were happening.

One of the problems was that glew-1.7.0 was installed in /usr/local/lib64, and my app was using this version of glew.

  • I found this by doing find /usr -name libGLEW*

And the other was that ldconfig did not know about /usr/lib64.

  • This was found by doing ldconfig -p > report.txt and looking to see what directories ldconfig was looking in. Which turned out to be helpful because I thought /usr/lib64 was a "trusted" directory, and that was not the case.

Armed with this information glew-1.7.0 was removed, ldconfig was updated and now everything works as expected.

tamato
  • 838
  • 7
  • 15