Windows OpenGL Linking problem?

silvano.cerza · wrote on 12 Jun 2017, 09:47

I'm trying to build an application that uses OpenGL on Windows with Qt 5.9 and MSVC 2017.
Problem is that it fails at build time since it can't find lots of external symbols like glBindBuffer , glDeleteBuffers and lots of other OpenGL functions, this makes me think that is not linking to correct version of OpenGL. How could I make it link to correct version?

m.sue · 12 Jun 2017, 12:31

Hi,

if you work with qmake .pro files you will probably just have to add LIBS += -lopengl32.

-Michael.

silvano.cerza · M m.sue 12 Jun 2017, 11:29

@m.sue Doesn't work, it links the system library and it's too old since it's version 1.1.

m.sue · 12 Jun 2017, 14:44

Hi,

that can mean that

you do not have the driver of your graphic card installed (properly), which would overwrite system-library, or
you use angle, or
you use software rendering.

What is it that you use?

-Michael.

silvano.cerza · M m.sue 12 Jun 2017, 12:49

@m.sue GPU drivers are updated to latest version, using an Nvidia GeForce GTX 970, driver version is 369.09.
I don't think I'm using Angle nor software rendering. How can I be sure that it's not using those though?

Chris Kawa · 6 Dec 2017, 15:39

glBindBuffer is a function of OpenGL >= 2.0, which means it is resolved dynamically at runtime. It should not be linked at all.
Qt resolves these functions and exposes them through QOpenGLFunctions. Are you using that class or trying to call them directly?

If you're using the prebuilt binaries then Angle/Desktop selection happens at runtime. If your app is not even linking then you're still way away from that point.

silvano.cerza · wrote on 12 Jun 2017, 15:56

@Chris-Kawa I'm using a third party library, QNanoPainter, which uses NanoVG as rendering backend, from my understanding it uses QOpenGLFunctions. I should have said that in first post I think.

I'm using the precompiled binaries.

silvano.cerza · wrote on 13 Jun 2017, 08:31

I was wrong, it doesn't use QOpenGLFunctions, NanoVG makes raw OpenGL calls.

Chris Kawa · wrote on 13 Jun 2017, 13:53

Right, the library doesn't seem to be very Windows friendly. It assumes the pointers to GL functions resolved and available in global scope, which is not how it usually works on this platform. Moreover it seems to force ANGLE and OpenGL ES (or at least tries to) on Windows in the .pri file, but then is inconsistent in how it checks for that.

I'd say contact the authors and ask them to fix the Windows parts.