I'm writing an application that uses Qt, and I'd like to make it available to Windows users. I'm using mingw. I want to configure Qt with -exceptions as well as -static. Is this possible? I've found a post on a blog that states that static builds with mingw and exceptions will cause memory leaks:
http://blog.lugru.com/2010/04/static-qt-compilation-and-mingwm10-dll-mingw-confusion/
Some of my code throws exceptions, which should be handled in the GUI part of my code by displaying an error dialog (meaning: I don't want to remove all exceptions from my code).
I tried to build Qt with both -static and -exceptions and it didn't seem to work (I still got error messages about exceptions when I tried to compile my code). I won't rule out the possibility that I somehow messed that up, but if these options are mutually exclusive, it would be nice to know before I spend all day compiling Qt again. Thanks!
Related
I have a reMarkable tablet , which I mostly love except for the lack of linux support (surprising given it is a linux-based OS). However, I've managed to find a version of a linux application that is now unofficial. This github is actually a Qt docker app, but if you look in the code for the 'Dockerfile' you can find where to download the app, which is apparently still on the server even though there's not a link from the main web page. Anyway, I downloaded it and got it mostly working, figuring out a few dependencies based on same Dockerfile code. But, I can't seem to get file dialogs to work, which is the main reason for using the app.
The error I get is:
ERROR: No native FileDialog implementation available.
Qt Labs Platform requires Qt Widgets on this setup.
Add 'QT += widgets' to .pro and create QApplication in main().
I'm not a Qt developer, so I'm lost. I'd love to get this to work. Thanks.
In the .pro file of you project you should add this line QT += widgets
or just add widgets to the line with QT += ...
Qt can use native file dialogs on some platforms, and will fall back to its own implementation if none is available. But that requires that the application is built including the QtWidgets module, and using a QApplication.
If you don't have the source code of the app and a possiblity to rebuild it, there's no chance to fix this from a binary
How can I stop this warning in Qt 5.4.1 in Debug/Release mode.
QOpenGLContext::swapBuffers() called without corresponding makeCurrent()
It only appears in debug mode, but release mode is fine with VS2010.
It appears in both modes (Debug & Release) with QtCreator.
I have tried so many ways to remove it but no success, searched google but couldn't find any useful info.
Plateform: Windows 8.1- VS2010- Qt_Creator Nvidia GTX 765
Thanks.
Serious answer: By filing a bug report with the Qt developers. Calling SwapBuffers on a drawable without a OpenGL context bound to it is perfectly fine. Actually SwapBuffers does not belong to the OpenGL context but to the window, so having that method placed in QGLContext is a big design failure itself.
Personal rant (in the hope some Qt devs are going to see it, eventually):
These guys (like every other toolkit developer community I got the impression) really need some summer school in how OpenGL works and what you should and should not do. I know of no toolkit that gets OpenGL context management right. If developing a toolkit wasn't such a huge amount of work I'd go "Fine, I'll develop my own GUI toolkit, with Blackjack and hookers…"
You should fix your code, instead of suppressing warning. You may show an SSCCE, if you want some hints from community.
But if you still want to suppress warnings, you need to follow Qt documentation
There is a known bug in QtCreator: under Windows it cannot handle correctly compiler native messages.
When using MinGW it's all ok since it produces messages in English. But there is no Qt5 binaries for MinGW (and I don't want to build my own ones, since, I guess, it painful process). So I try to use MSVC. But, my MSVC prints error mesages in Russian. After QtCreator processes these messages it shows me something unreadable.
For now google didn't help me how to solve this problem.
Does anybody know the way to configure QtCreator? Or configure MSVC to print errors in English? Or even modify QtCreator's source putting some stub and "fixing" the problem?
I've built Qt from sources with MSVC2008 as it was recommended to avoid any incompatibility issues. I'm having a problem though when using Qt functions that return QList objects.
QList<QNetworkInterface> *netInterfaces = new QList<QNetworkInterface>;
*netInterfaces = QNetworkInterface::allInterfaces();
delete netInterfaces;
This code will always crash on "delete netInterfaces" in free.c when trying to free memory. It states the heap is corrupted and I have no idea why, as everything was compiled with the same version of MSVC.
It happens for all Qt functions that return QList objects even when I just call the function:
QNetworkInterface::allInterfaces();
With the code above, application will always crash immediately when trying to free heap allocated by Qt.
Weird thing is, this only happens with the Debug build. Release build works fine without any crashes.
My Qt 4.8.0 was compiled with /MT (Multi-threaded) and I link to the library dynamically. My application is also compiled as Multi-threaded.
Does anyone know what could be the possible cause of the issue here?
I've found the solution to my problem. Apparently Qt has it's own set of heap allocators and while I had a Multi-threaded (/MT) build and a shared library, Qt would allocate heap using their own memory handlers in the DLL. After this memory was allocated by Qt, my application was trying to free these memory blocks in my own code which resulted in crashes as heap structure differed between Qt and the main application.
I've rebuilt Qt with /MT flag, but now I produced a static library instead of the shared one. After I linked Qt statically with my application all heap problems magically went away.
I may be wrong a bit with my explaination here, but I hope at least the solution will help some people who find this thread. I've seen quite a few people having this problem on the internet and the key is to actually understand that you shouldn't link shared library when it's built with /MT flag. /MD would be totally fine.
Here is the thread I found that enlightened me: http://qt-project.org/forums/viewthread/16513
Cheers!
I am currently using QtCreator 2.4.1 with Qt 4.7.4 development libraries (in Ubuntu) and am trying to track down a bug which after profiling with valgrind seems to occur internally within QGraphicsView::paintEvent(…) method
To help isolate this problem I would like to step into the Qt sources. Having done some searching through both the Qt forums and stack overflow and have not being able to find a way to integrate the sources with my version of QtCreator.
I have currently tried downloading the sources via the QtSDK manager and adding a “Source Path Mapping” within Tools->Options->Debugger. I am sure that this step is where I am making a mistake as I am unable to even switch to source when viewing internal Qt header files i.e. from QGraphicsView.h
I have so far tried adding the following Source Path Mappings
Source Path=/var/tmp/qt-src
TargetPath=/home/paul/QtSDK/QtSources/4.7.4
and
Source Path=/var/tmp/qt-src
TargetPath=/home/paul/QtSDK/QtSources/4.7.4/src
Neither works.
I have also tried building Qt directly from source, adding this to my "Qt versions" list within Qt Creator and creating a new project configuration using this version. This also did not work.
Likewise I have tried adding the src folders to my gdbinit file. This also fails to work.
I am completely lost with this.
Paul
Someone asked a similar question here: Need to step into Qt sources (my IDE is Qt Creator).
Someone else asked about Valgrind errors with Qt here: Suppression files for Qt memory leaks with Valgrind
And here is a little more info about Using Valgrind with Qt Creator along with some explanation about how to read the results. Its a little dated from late 2010.
Related Suggestions
I wouldn't debug the QGraphicsView class just because of all the effort to make it work or find the problem might be for nothing... Qt is moving to using the SceneGraph as the backend for QML and the rendering engine for QGraphicsView might become obsolete.
Updating to the latest stable build of the Qt libraries may make a big difference for QGraphicsView.
If you post the valgrind error you are getting to the Qt Trolls, someone might be able to explain what is going on for you.
There are other debugging techniques besides the traditional debugger. I've been programming in Qt in Windows (without valgrind) and with a large multi-threaded application, that loads a bunch of Dll's. I've had to put some faith into the Object Tree Model clean up and work on all the new calls I put in. Most of the time I just use QDebug to find errors. Then I am also using a combination of qInstallMessageHandler() with QDebug to implement decent logging for the hard to track bugs.
See also Qt Debugging Techniques.