QCoreApplication::instance() is NULL
-
@ambershark said:
Do you have any Qt global variables that could be initialized before your main? I had that exact problem and my issue was a global Qt variable.
I can't remember the exact type, but let's just say a QObject, that was not a pointer and therefore had initialization before the main() and QCoreApplication.
It was also in a .so outside of the main application, which may have contributed to the issue as well.
Hi ambershark,
as I described above, I already tracked down the reason why the executable doesn't work: linking against both, debug and release version of
Qt5Gui
andQt5Widgets
. Now I only need to find the reason why it happens, which is much easier now the core problem was tracked down. -
News: I can't seem to get rid of the dependencies to
Qt5Widgets
,Qt5Gui
andQt5Core
in my executable, even after excluding a lot of submodules and their headers which could have been the cause. The symbols listed in depends.exe for the release DLLs are not giving me any hint where the import results from.Now comes my general question: what could possibly cause a debug build to refer to the release versions of the Qt5 DLLs? As far as I understand Qt, it would have to be some header file included without
QT_DEBUG
being defined. Is there perhaps a chance to closely inspect the generated Makefiles to see why and where this is happening?Despite the fact I now know the reason for the problem, I can't find the cause, i.e. why does my executable being built in debug mode want to link against Qt5 release DLLs. I'm stumped.
-
Add
QT -=core gui widgets
to your .pro file?
-
@sierdzio said:
Add
QT -=core gui widgets
to your .pro file?
I first thought you were kidding me, but this even works for my main *.pro file.
This seems a little.. umm.. counter-intuitive and the opposite of what the the help for theQT
qmake variable suggests, no!? -
Not sure what you mean.
By default, QT contains both core and gui, ensuring that standard GUI applications can be built without further configuration.
So, if you don't want to link them, remove them. As I understand from (brief, I admit) look at your previous comments, you aim to remove all traces of Qt libs from the project, to pinpoint the place where the release libs are injected.
I know this might be a stupid approach, but when everything else fails... :-)
-
@sierdzio said:
Not sure what you mean.
By default, QT contains both core and gui, ensuring that standard GUI applications can be built without further configuration.
Yeah, sure, this has been the case since Qt4 AFAICT. I mean that removing "core gui widgets" from a main *.pro file where QMainWindow and QWigets etc. are used is counter-intuitive.
@sierdzio said:
So, if you don't want to link them, remove them. As I understand from (brief, I admit) look at your previous comments, you aim to remove all traces of Qt libs from the project, to pinpoint the place where the release libs are injected.
This is a good idea at least! I would never have thought of trying to remove everything from
QT
execpt what is really needed (e.g. xml, network, ...).I know this might be a stupid approach, but when everything else fails... :-)
Thank you for the hint. It may really help me find the bad guy :-)
-
The issue is solved!
After an odyssey of trial and error, the culprit is or was static libraries!
Within our project there were two submodules built as static libraries (
CONFIG += static resources create_prl
) and linked to several other submodules. The static libraries were built with the same project settings, i.e. DEBUG enabled, and still they were the root cause of my problems.It has to be either the
link_prl
in the project, or generally linking against static libraries which causes our project to import the unwanted non-debug Qt5-DLLs in a debug build.After converting the static libraries to DLLs with export symbols now everything works as expected.
I don't know if this problem and its workaround should be considered a Qt5 bug, or if it is my fault because of not having read some documentation part mentioning this specific fact?
Thanks for all your help and cheers!
Jürgen -
Nice.
You might want to ask this on Qt development mailing list, the Qt core developers could probably comment on that weird release symbol linking.
-
Since I don't know if you are using a shadow build, are you using the same names for your static debug release libraries ? Are you putting them in the same folder ?
If so you might be linking to a release version of your lib accidentally which in turn would pull the release Qt libraries.
-
After posting to Qt development ML and getting a reply, an even simpler solution is to just
CONFIG -= debug_and_release
in the *.pro files of the staticlib submodules. I don't know why, but
debug_and_release
seems to be a default. My project, developed with QtCreator since Qt4, doesn't define this flag. -
@SGaist said:
If so you might be linking to a release version of your lib accidentally which in turn would pull the release Qt libraries.
I'm using QtCreator and have separate shadow build directories for debug and release. The culprit was the
debug_and_release
flag inCONFIG
which I have to remove in the *.pro files... -
Still a bit strange but glad you found a solution :)