[SOLVED] GLEW linking errors with Qt Creator 2.5.2



  • Hi all,

    First off, I'm sorry if this has been asked multiple times but I've browsed through many posts relentlessly and none offered a solution to my problem.

    I'm currently running Qt Creator 2.5.2 on Windows 8.1 using Qt 4.8.5 and I'm trying to link GLEW 1.10.0 but I keep getting these linking errors such as:

    • undefined reference to '_imp_glewExperimental'
    • undefined reference to '_imp_glewCreateShader'

    What I don't understand is my program is able to find GLuint and locate GL/glew.h. I even tried dragging the glew.h file into my directory and I still get the same errors. What's interesting is when I #define GLEW_STATIC, I get the same errors but without the _imp

    I installed GLEW from "here":http://glew.sourceforge.net/ glew-1.10.0-win32.zip

    .
    Here is my .pro file:
    @QT += core gui opengl widgets

    TARGET = ObjLoader
    TEMPLATE = app

    SOURCES += main.cpp
    ViewerMainWindow.cpp
    GLDisplay.cpp
    readOBJ.cpp
    glheader.cpp

    HEADERS += ViewerMainWindow.h
    GLDisplay.h
    readOBJ.h
    glheader.h

    INCLUDEPATH += F:/Graphics/glm
    INCLUDEPATH += F:/Graphics/glew-1.10.0/Include

    INCLUDEPATH += F:/Graphics/glew-1.10.0/lib/Release/Win32
    DEPENDPATH += F:/Graphics/glew-1.10.0/lib/Release/Win32

    LIBS += -LF:/Graphics/glew-1.10.0/lib/Release/Win32 -lglew32 -lglu32 -lopengl32@

    The header file of the error source:
    @#ifndef GLHEADER_H
    #define GLHEADER_H
    #include <QtGlobal>
    #include <iostream>
    #include <string>

    #include <iostream>
    #include <string>
    //#if defined(Q_OS_WIN32) || defined(Q_OS_WIN64)
    #define GLEW_STATIC
    #include <GL/glew.h>

    void glSetup();
    GLuint LoadShaders(const char *, const char *);

    #endif // GLHEADER_H@

    And the cpp file:
    @#include "glheader.h"
    #include <fstream>
    #include <stdio.h>
    #include <vector>
    #include <QMessageBox>

    using std::cout;
    using std::endl;
    using std::string;
    using std::ifstream;

    void glSetup()
    {
    #if defined(Q_OS_WIN32)
    glewExperimental = true;
    GLint GlewInitResult = glewInit();
    #endif
    }

    GLuint LoadShaders(const char *vertexFilePath, const char *fragFilePath)
    {
    GLuint VertexShaderID = glCreateShader(GL_VERTEX_SHADER);
    GLuint FragmentShaderID = glCreateShader(GL_FRAGMENT_SHADER);
    }@

    Any help or example links would be greatly appreciated, thanks!


  • Moderators

    This works for me:
    @
    INCLUDEPATH += "C:/foobar/glew-1.10.0/include"
    LIBS += -L"C:/foobar/glew-1.10.0/lib/Release/Win32" -lglew32
    @
    You don't need tpo explicitly link to opengl32 (and glu I think). Qt + opengl does that for you. You also don't need to add lib folder to INCLUDEPATH, no headers there. If you're not building glew everytime you don't need the DEPENDPATH either.
    Remember to re-run qmake (Build->run qmake) after changes in .pro file so it will pick up new directories.



  • I modified my .pro to have just those 2 lines you posted but I'm still getting the same linking errors. Is there something that I may be missing externally? Or could there be a possibility that other packages be conflicting with the linking?

    And I constantly run qmake with every change made


  • Moderators

    Not that I know of.
    Just to be sure - build or rebuild is not the same as running qmake.
    What compiler are you using - MinGW or VC and which version?

    Offtopic question - why still Creator 2.5.2? It's very old. Current version is 3.1.0



  • I believe I'm using MinGW. I don't know how to check the version. I obtained my current version of MinGW from installing QtSDK at this "link":http://download.cnet.com/Qt-SDK/3000-2069_4-75305206.html

    Addressing your off topic question -
    I'm using Creator 2.5.2 because I believe that's what my Graphics class used last year. I tried using Creator 3.1.0 but I didn't understand how a kit worked and how to install one. I just wanted to continue my project from last year right away and over time, switch to Creator 3.1.0



  • Actually, it's better to say my tool chain has auto-detected both MinGW (as a GCC for Windows targets) and MSVC Visual C++ Compiler 12.0. But when I'm compiling, it's using mingw32-make.exe


  • Moderators

    Hm, I might be wrong, but aren't the binaries distributed with GLEW incompatible with MinGW? I think you need to compile GLEW from source using MinGW.

    The SDK you have is also quite old. The best way to install all you need is usually via online installer directly from "Qt downloads page":http://qt-project.org/downloads
    It will allow you to select a version and compiler you want and will set up kits and all the stuff for you.
    A kit is actually just a collection of tools in the chain needed for development: a compiler, debugger and a Qt library packed in one, named configuration that you can select when creating project.



  • Thanks for the explanation on a kit. I went and installed the "Qt Online Installer":http://qt-project.org/downloads, and was surprised that everything was set up for me.

    So now I believe I'm running the latest Qt Creator, which came with the installer. I'm now running the following:

    • Compiler: MinGW 4.8 32bit
    • Qt 5.2.1

    I'm still getting the same errors.

    You also mentioned about the binaries distributed with GLEW may be incompatible with MinGW. How do I compile GLEW from source using MinGW, and what does that do?


  • Moderators

    Yeah, the binaries (dll and lib files) are built with some old version of VC (not sure which) and it seems they don't play well with MinGW.

    Download the "source package":https://sourceforge.net/projects/glew/files/glew/1.10.0/glew-1.10.0.zip/download of GLEW
    If you don't know how to compile it look around on the web. I can't give you specific instructions since it's been a while since I used GLEW and MinGW together, but it should be as easy as setting some environment variables and running mingw32-make with some options.

    What it does - it creates libraries compiled by and compatible with MinGW ;) You see the .dll file in the bin folder and .lib in the lib folder? The .lib one is the one you use with the LIBS entry in your .pro file, the .dll is needed at runtime and you distribute it with your app.
    Compiling with MinGW will create these (except the .lib one will have .a extension, that's the "native" format of MinGW).


  • Moderators

    I was just thinking - do you really need GLEW at all? Qt has pretty nice OpenGL supporty built in and it can resolve all the function pointers just as GLEW does.
    You can just subclass QOpenGLFunctions_4_3_Core (or whichever OpenGL version you want to target) and use OpenGL inside it like you would normally.



  • Thanks for the explanations. And I did not know about the class QOpenGLFunctions. I checked it out and it has the same function calls from GLEW. This is amazing! I will be away from my main computer for a few days so I'll test it out once I get back.



  • Okay, so I have completely abandoned GLEW in favor for "QGLFunctions":http://qt-project.org/doc/qt-5/qopenglfunctions-4-3-core.html and it is now working. If anyone else is interested, here is how part of my code is set up:
    @#include <QGLWidget>
    #include <QOpenGLFunctions_4_3_Core>
    #include "readOBJ.h"

    class GLDisplay : public QGLWidget, protected QOpenGLFunctions_4_3_Core
    {
    public:
    GLDisplay(char *, QWidget *parent = 0);
    void createOBJ(char *);
    GLuint loadShaders(const char *, const char *);
    @

    Also, it appears that in order to use QOpenGLFunctions_4_3_Core, you have to call "setSurfaceType":http://qt-project.org/doc/qt-5/qwindow.html#setSurfaceType(OpenGLType) from the QWindow class. Otherwise, Seg Faults will occur.

    If QOpenGLFunctions is used instead, then this is not necessary, but QOpenGLFunctions lack certain functions that _4_3_Core has (i.e. glGenVertexArrays() to set up VAO).

    Thanks again Chris.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.