Resolving OpenGL functions using glew in QT - qt

Its been 17 days I'm struggling to write a simple program in OpenGL using QT, but all tutorials searched on Google are failed.
I'v compiled my QT 5.0.1 with -opengl desktop using msvc2010 to make desktop opengl default.
I'v read tutorial by Sean Harmer, but it is depended on QT to resolve opengl functions.
According to some people, it is not possible to use glew in QT, as QT's built in libraries prevent glew from including its headers, but according to Sean Harmer HERE , it is possible (but it is not explained there how).
Even using QGLWidget I'm not able to use OpenGL extensions.
Now all I want is to use all OpenGL functions separate and all windowing functions from QT separate, i.e. no interference in OpenGL by QT.
If anybody explain me the procedure with simple triangle example and using any extension, I'l be so thankful..
I'v used glew library in my project and #included glew.h in very start of my program, but when compiled it gives error:
glwidget.obj:-1: error: LNK2001: unresolved external symbol imp__glewGenVertexArrays
My .pro file
QT += core gui opengl
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = Trial
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp \
glwidget.cpp
HEADERS += mainwindow.h \
glwidget.h
FORMS += mainwindow.ui
RESOURCES += \
resources.qrc
win32: LIBS += -L$$PWD/../../../../../OpenGL/glew-1.9.0/lib/ -lglew32s
INCLUDEPATH += $$PWD/../../../../../OpenGL/glew-1.9.0/include
DEPENDPATH += $$PWD/../../../../../OpenGL/glew-1.9.0/include
win32: PRE_TARGETDEPS += $$PWD/../../../../../OpenGL/glew-1.9.0/lib/glew32s.lib
Output by glewInfo :
GLEW version 1.9.0
Reporting capabilities of pixelformat 1
Running on a GeForce GT 540M/PCIe/SSE2 from NVIDIA Corporation
OpenGL version 4.3.0 is supported
void GLWidget::initializeGL()
{
GLenum err = glewInit();
if(err != GLEW_OK)
{
printf("%s",glewGetErrorString(err));
}
glEnable(GL_DEPTH_TEST);
qglClearColor(QColor(Qt::red));
shaderProgram.addShaderFromSourceFile(QGLShader::Vertex, ":/vertexShader.vsh");
shaderProgram.addShaderFromSourceFile(QGLShader::Fragment, ":/fragmentShader.fsh");
shaderProgram.link();
shaderProgram.bind();
const GLubyte *oglVersion = glGetString(GL_VERSION);
printf( "%s\n",oglVersion );
GLfloat vertices[3][3] ={{ -0.5, -0.5, -1 },
{ 0, 0.5, -1},
{ 0.5, -0.5, -1}};
vertexArray.create();
vertexArray.setUsagePattern(QOpenGLBuffer::StaticDraw);
vertexArray.allocate( vertices, 3 * 3 * sizeof( GLfloat ) );
vertexArray.bind();
shaderProgram.setAttributeBuffer( "vVertex", GL_FLOAT, 0, 3 );
shaderProgram.enableAttributeArray( "vVertex" );
GLuint arr[5];
glGenBuffers(5,arr);
}

All problems solved now.
First problem was : QT 5.0.1 does not support opengl by default.
You have to compile it with -opengl desktop.
Here is tutorial on how to compile QT with vs2010.
Or you can download new opengl build from QT.
Second problem in adding glew libraries to project.
If you add glew32s.lib (static) then you have to add "#define GLEW_STATIC" before "#include "
It is advised to use glew32.lib (dynamic).
Third problem was segment fault on some opengl functions even if your GPU supports version 4.3.
GLEW obtains information on the supported extensions from the graphics driver. Experimental or pre-release drivers, however, might not report every available extension through the standard mechanism, in which case GLEW will report it unsupported. To circumvent this situation, the glewExperimental global switch can be turned on by setting it to GL_TRUE before calling glewInit(), which ensures that all extensions with valid entry points will be exposed.
Took 18 days to solve these problems, glad now can start actual programming.

Following code compiles just FINE on MSVC2008 express, qt 4.8.1 and glew version 1.7.0
main.cpp:
#include <GL/glew.h>
#include <QApplication>
#include <QGLWidget>
int main(int argc, char** argv){
glewInit();//<<-- glew function
QApplication app(argc, argv);
QGLWidget widget;
GLuint arr;
glGenVertexArrays(1, &arr);//<--no linker error (added just for testing, most likely won't gen arrays)
widget.show();
return app.exec();
}
gltest.pro:
TEMPLATE = app
TARGET =
DEPENDPATH += .
INCLUDEPATH += . d:/c++/libs/include
LIBS += -L"d:/c++/libs/lib" -lglew32
CONFIG += console
QT += opengl
# Input
SOURCES += main.cpp
I assume that with Qt 5 situation won't be any different.
Feel free to override QGLWidget's paintGL and draw whatever you want using extensions. I don't have a code snippet nearby for that.
Suggestions:
1. Use precompiled binaries.
2. It might make sense to use dynamically-linked version of glew.
3. Notice header inclusion order.
According to some people
People say many things, you don't need to believe all of them.

I would like to share my latest finding about how to make Qt and glew work together on the (currently) latest Windows environments (Qt 5.15.1 + QMake + MSVC 2019 + glew 2.1.0). Hope someone else an avoid spending countless hours on this like me. Here are what I did:
Copy glew32.dll and glew32.lib to somewhere in your project directory. Make sure to the bitness of glew matches with the bitness of the executable you told Qt to build. I did not use the static version of the library because I failed to make that work.
In your .pro (QMake) file, write something like this:
GLEW_INCLUDE_PATH = "$$PWD/ext/glew/include" # put glew headers here
GLEW_LIB_PATH = "$$PWD/ext/glew/x64" # put glew32.dll and glew32.lib here
LIBS += -L$$GLEW_LIB_PATH -lglew32 -lglu32 -lopengl32
DEPENDPATH += .
INCLUDEPATH += $$GLEW_INCLUDE_PATH
The only difference I made compared to the previous answers is that I added -lglu32 and -lopengl32 to the link arguments. It seems that they are mandatory on Windows, othewise MSVC will complain about some link errors with OpenGL API functions.
Additionally, try using QOpenGLWidget instead of QGLWidget. QGLWidget caused some weird OpenGL "Invalid Operation" errors when my program is exiting and trying to destroy OpenGL handles such as buffer and texture handles in destructors. glIntercept showed me that it is because wgl context was destroyed before the handles get released. Switching to QOpenGLWidget solved this problem completely.
Hope you can enjoy using glew with Qt now!

Related

Qt Deployment error 0xc0000007b on Windows

I have a Qt 5.12 Windows app. I'm using Qt Creator and Mingw 64 bit.
I've deployed the app by windeployqt.exe. When I start it, the app requires the libgcc_s_seh-1.dll file. After I paste it in the dir, I get the 0xc000007b error. I ran Dependency Walker and it gives me the following errors:
Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Error: A circular dependency was detected.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
This is my .pro file
QT += core gui network
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = Control
TEMPLATE = app
# The following define makes your compiler emit warnings if you use
# any feature of Qt which has been marked as deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS
# You can also make your code fail to compile if you use deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0
QMAKE_LFLAGS += -static-libgcc
##CONFIG += c++11
##QMAKE_CXXFLAGS += -std=c++0x
SOURCES += \
main.cpp \
mainwindow.cpp
HEADERS += \
mainwindow.h
FORMS += \
mainwindow.ui
# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target
Can someone help me? Thank you very much.
I had a similar problem in the past, but I am not pretty sure if it's the same reason because I was compiling with MVSC.
In my case, the application internally links with x86 dependency files. I did download and install x64 dependency files and link with x64 files.
Anyway, the old version of Dependency Walker doesn't know to skip 32-bit DLLs in PATH when processing a 64-bit EXE or DLL the way Windows does, so some errors are not really relevant. You may find more information in this post.
If the problem remains, try to avoid the usage of a static version of libgcc, acording to this post. It is not designed to be statically linked.
...
#QMAKE_LFLAGS += -static-libgcc
...
I got that error when the compiled app could not see the Qt dlls, so check your path. It could also be that it cannot find other gcc dll, like libwinpthread-1.dll.

Qt and Boost (installed through Homebrew) result in Qt compile errors

I am in the exact situation described in this question (Qt Creator on Mac and boost libraries) but the accepted answer is not working for me. I've searched around and tried all the suggestions I've found but I still end up with errors
Environment:
OSX 10.9.5
Qt 5.5.1 - Qt Creator 3.5.1 - installed using the Qt
installer
Boost 1.59.0 – installed through Homebrew
Am able to compile and run Qt apps
After creating a new Qt test application, when I add the Boost information to the .pro file (shown below) as described in the question linked above, I end up with very confusing compile errors within the Qt classes. I don't get it. Does anyone understand the conflict and know how to resolve this – I've been at it for hours now.
QT += core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = audiowaveform_test
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp
HEADERS += mainwindow.h
FORMS += mainwindow.ui
macx {
QMAKE_CXXFLAGS += -std=c++11
_BOOST_PATH = /usr/local/Cellar/boost/1.59.0
INCLUDEPATH += "$${_BOOST_PATH}/include/"
LIBS += -L$${_BOOST_PATH}/lib
## Use only one of these:
LIBS += -lboost_chrono-mt -lboost_system # using dynamic lib (not sure if you need that "-mt" at the end or not)
#LIBS += $${_BOOST_PATH}/lib/libboost_chrono-mt.a # using static lib
}
I finally got it working by changing this line in the .pro file:
QMAKE_CXXFLAGS += -std=c++11
to this:
CONFIG += c++11
If someone can explain what -std means in compiler speak, I would appreciate it. Does it mean that everything should be compiled as c++11?

Conflict between qDebug and SDL

I work on Mac OS 10.8.5 and Qt 5.1.1 with among other things, qdebug class which work well with some projects and doesn't compile with some others. I've already tried to re-install Qt which didn't change a thing.
It is certainly due to the use of SDL library (?!) but it used to work fine. Here's a part of the compilation output :
In file included from ../../Stage/Joker/tests/SDLTest/main.cpp:7:
In file included from /Applications/QT/5.1.1/clang_64/include/QtCore/QDebug:1:
In file included from /Applications/QT/5.1.1/clang_64/include/QtCore/qdebug.h:46:
In file included from /Library/Frameworks/QtCore.framework/Headers/qhash.h:46:
/Library/Frameworks/QtCore.framework/Headers/qchar.h:76:5: error: unknown type name 'QT_ASCII_CAST_WARN_CONSTRUCTOR'
QT_ASCII_CAST_WARN_CONSTRUCTOR QChar(char c);
^
If needed, I can provide more output or unworking Qt classes.
I build my code with Qt => Build => Run
Unfortunatly, I'm unable to reproduce the code on an other computer.
Here's the pro file (which work well with all my co-workers, except me) :
TEMPLATE = app
SOURCES += main.cpp
OBJECTIVE_HEADERS += ../../libs/PhGraphic/SDLMain.h
OBJECTIVE_SOURCES += ../../libs/PhGraphic/SDLMain.m
LIBS += -framework Cocoa
QMAKE_CXXFLAGS += -F/Library/Frameworks
QMAKE_OBJECTIVE_CFLAGS += -F/Library/Frameworks
LIBS += -F/Library/Frameworks
LIBS += -framework SDL -framework SDL_image -framework SDL_ttf
I'd once had this problem after installing a software: it created a QtCore.framework in the /Library/Framework folder that overrided the QtCore of your current Qt kit (due to QMAKE_CXXFLAGS += -F/Library/Frameworks).
It's qDebug, and there are two overloads:
a stream-returning function
qDebug() << "foo";
a printf-style function
qDebug("foo");
You need to provide a minimum reproducible test case for us to help you.
How are you building your code? Are you using qmake to produce the Makefile? We'd need to see the .pro file at the minimum, and please minimize it by removing useless boilerplate comments etc.

Qt linker errors: cannot find -lQtCored

A problem with a Qt *.pro file:
TARGET = ProgName
TEMPLATE = app
CONFIG += console
QT += core
QT += gui
LIBS += -LC:\\Qt\\4.8.5\\bin
LIBS += -LC:\\Qt\\4.8.5\\lib
LIBS += -LS:\\lib
# LIBS += -lQtCored4 # not necessary
# LIBS += -lQtCore4
# LIBS += -lQtGuid4
# LIBS += -lQtGui4
SOURCES += ...
HEADERS += ...
I get these linker errors:
:-1: error: cannot find -lQtGuid
:-1: error: cannot find -lQtCored
collect2.exe:-1: error: error: ld returned 1 exit status
All the DLLs exist in the specified directories.
The documentation did not help much.
This pro file worked a few days ago, and it seems to have issues since I installed Qt 5.1 (this is not used, yet; I am still working with Qt4).
Platform: Windows 7, MinGW, Qt 4.8.4
You only need the following content:
TARGET = ProgName
TEMPLATE = app
CONFIG += console
QT -= gui
SOURCES += ...
HEADERS += ...
That is because core and gui are added to the QT variable automatically. In this particular case however, you can remove the gui default if you wish to build a console application as you seem. Although "CONFIG += console" could eventually do that for you. Besides this, everything will work automatically for you, so you do not need to pass the library path to the qt libraries and so forth. You would only need to use QT += widgets and similar lines if you used further Qt modules there are not there by default. Even then, you would not need to set the Qt library path as you did in your question.
Besides, if you wanna target cross-platform later, you may wish to add this:
CONFIG -= app_bundle
to avoid creating Mac bundle for console based applications.
If you have multiple versions of Qt installed as it seems, you need to use the qmake from the required version, and it will be fine. Just to give an example: I use qmake for Qt 5 on my Archlinux system, and qmake-qt4 for Qt4.
On windows, you should either have the desired qt installation bin in the path before the undesired, or you need to call desired qmake explicitly, something like C:\path\to\my\desired\qmake.
There's no need to link to any Qt libraries afaik.
If you're using Qt Creator you need to make sure Qt 4.8.4 is properly recognized in Tools - Options - Build & Run - Kits. Since you installed 5.1 this may no longer be true. Then set the 4.8.4 kit for your project and compile it (cleaning the build directory also helps sometimes).

How to add specific flags to moc in a qmake project?

I compile a Qt executable using qmake && make on the following project.pro file:
INCLUDEPATH *= ../../dependencies/boost
QT *= opengl xml
CONFIG *= qt opengl static
TARGET = myexe
HEADERS = Viewer.hpp MainWindow.hpp Inspector.hpp
SOURCES = main.cpp Viewer.cpp MainWindow.cpp Inspector.cpp
However, when compiling, moc chokes on a boost macro which it cannot parse. To work around this bug, I need to pass the flag -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED to moc, but I cannot manage to do so.
How to I edit my .pro file to pass a given flag to moc? (but not to g++, as QMAKE_CXXFLAGS does)
A bit hackish, but what about if you overwrite the moc compiler so that it includes the flag. In the .pro:
QMAKE_MOC = $$QMAKE_MOC -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED
In my code in header files I just have:
#ifndef Q_MOC_RUN
//Here we include Boost or Ogre headers with Macro
#endif
It works perfectly in Qt5 x64 and need not recompiling anything.
There is an update to this issue for boost 1.53, see the last post here:
We need to add -DBOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION also.
For add specific flags to moc in a qmake project(qt5.2) need:
load(moc)
QMAKE_MOC += -DBOOST_INCLUDE_GUARD_GOES_HERE
The best way I found to do this is based on a comment on the accepted solution from David Faure:
QMAKE_MOC_OPTIONS += -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED
The other proposed methods that involve load(moc) and manipulating the QMAKE_MOC variable itself have an unfortunate side effect: they prevent qmake from automatically adding INCLUDEPATH variables (and maybe others) that would normally be on moc's command line, if INCLUDEPATH is set up after the call to load(moc).
This approach composes easier if you have your qmake configuration split up to multiple files; you don't need to ensure that the change to the moc command line comes after all INCLUDEPATH directories are set.
See for example the Qmake docs for variables which details
ten different variables in the QMAKE_CFLAGS_* pattern, and
ten different variables in the QMAKE_CXXFLAGS* pattern
and hence I would start with QMAKE_CXXFLAGS which is documented as:
QMAKE_CXXFLAGS
This variable contains the C++ compiler flags that are
used when building a project. The value of this variable is typically
handled by qmake or qmake.conf and rarely needs to be modified. The
flags specific to debug and release modes can be adjusted by modifying
the QMAKE_CXXFLAGS_DEBUG and QMAKE_CXXFLAGS_RELEASE variables,
respectively. Note: On the Symbian platform, this variable can be used
to pass architecture specific options to each compiler in the Symbian
build system. For example:
QMAKE_CXXFLAGS.CW += -O2
QMAKE_CXXFLAGS.ARMCC += -O0
For more information, see qmake Platform Notes.
So I'd start with
QMAKE_CXXFLAGS += -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED
which you can just add to your .pro file.
In case you are doing Ogre3D (OGRE 1.8.1 SDK for Visual C++ .Net 2010 (32-bit) ) then use QT5 32bit instead of the QT5 64bit version, it will pass.
Also consider this :
#ifndef BOOST_SYSTEM_NO_DEPRECATED
#define BOOST_SYSTEM_NO_DEPRECATED 1
#endif
I think it has been compiled (boost included) with 32bit thus i suppose i have to take src and recompile (using my 64bit) but thats another story where i wont go for now since OGRE 1.9 RC 1 SDK for Visual C++ .Net 2012 (64-bit) will be soon release on stable version.
Regards
EDIT 1 :
Downloaded Qt libraries 4.8.4 for Windows and configured my QT creator (the one coming with full QT5 and guess what …. Ogre3D is working like a charm when compiling on 4.8.4.
Qt 5.0.2 for Windows 32-bit (VS 2010, 485 MB)
Qt libraries 4.8.4 for Windows (VS 2010, 234 MB)
OGRE 1.8.1 SDK for Visual C++ .Net 2010 (32-bit)
I also mentionned it for who is interested here : http://qt-project.org/forums/viewreply/128660/

Resources