Edit
The answers to this post either say compile yourself - which I don't want do to - or install qtbase5-dbg which is not part of Ubuntu releases anymore. So is there no way to achieve this without this package? And shouldn't there be different debug symbols for each Qt 5.X version?
I'm trying to add Qt sources - which I installed along Qt both using the Qt Maintenance tool - to QtCreator but am not able to get it to work. I've already looked at various websites for help but still no luck. I need to step into the Qt sources to see how Qt3D works since I'm trying to develop a Qt3D widget.
As for many others, when I go to Options > Debugger and there under Source Path Mappings click on Add Qt sources... it adds /home/qt/work/qt as Source Path and /home/[my username]/Qt/5.14.2/Src (the latter being the folder I selected).
Since I can't step into the Qt sources I assume the Source Path is wrong. I tried to follow the steps from this answer but when I move the mouse over a function call in the call stack after stopping at a breakpoint doesn't yield any path - just the function name and address.
Someone also pointed out that the compiled Qt libraries must not include stripped when getting info from them like this: file libQt.... But this is what file libQt53DCore.so.5.14.2 gave me:
libQt53DCore.so.5.14.2: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=d764882c0c26814e30d63a4d4719143e14e4c735, not stripped
So I assume that's fine. Although I built Qt myself and file libQt53DCore.so.5.15.0 yields
libQt53DCore.so.5.15.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=88eeb269ff68f0b71e3612d1a538503676da3790, with debug_info, not stripped
i.e. an additional with debug_info.
Unfortunately, building Qt results in a 20 something GB build and I would have to do this for multiple Qt versions. So how can I setup QtCreator properly so that I can step into Qt sources.
A few minor versions ago, Qt added "Qt debug information files" to the maintenance tool.
They contain the debug information of the libraries.
Which means, if you debug and want to step into human readable Qt library code you have to install them.
Related
Qt 6 has removed the support for ANGLE for their OpenGL backend. Now I would still like to use ANGLE with Qt because I would like to run custom OpenGL code that is translated by ANGLE to Vulkan Linux and Direct3D on Windows. I've tried to use ANGLE in my Qt 6 application, but without success. What I have tried is:
Build ANGLE from source files (on Linux) as per instructions (ANGLE build instructions).
Copied the generated libGLESv2.so and libEGL.so files into application directory. Then in my CMakeFiles.txt I have added:
find_library(libGLESv2 GLESv2)
find_library(libEGL EGL)
target_link_libraries(MyApp PRIVATE ${libGLESv2} ${libEGL})
Then in my main file I have added
QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);
QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL);
My project links and builds fine, but the ANGLE backend seems to have no effect. It appears that Qt is still using the standard OpenGL implementation rather than the one provided by ANGLE (running QOpenGLContext::currentContext()->hasExtension("EGL_ANGLE_platform_angle") returns false when I set up my context).
Using QT_LOGGING_RULES=qt.qpa.gl=true,the logs show:
qt.qpa.gl: Choosing xcb gl-integration based on following priority
("xcb_glx", "xcb_egl") qt.qpa.gl: Xcb GLX gl-integration created
qt.qpa.gl: Xcb GLX gl-integration successfully initialized qt.qpa.gl:
Requested format before FBConfig/Visual selection:
QSurfaceFormat(version 3.0, options
QFlagsQSurfaceFormat::FormatOption(), depthBufferSize 24,
redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize
-1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace
QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile)
How can I correctly setup Qt to rely on ANGLE?
Okay,
When I asked for a buildable project that reproduces the problem I didn't mean a snippet of source without the CMakeLists.txt that is causing the problem. I spent a good 4 hours trying to duplicate your environment blind. Nobody uses Qt 6 because it is horrible.
The first problem is you can't "just copy" libs.
GLES libs
EGL libs
After copy
the build and runtime system wants its series of links. When you copy you loose that because you get multiple copies of the same file rather than one copy with a bunch of links. If you are going to use these libraries you need to use them from an installed location or the original build location.
I wanted to prove this solution to you rather than just tell you, but I ran into the same problem 98.5% of all developers run into when anything Android is installed near Qt.
I wanted you to look at the CMakeLists.txt file for WaylandGUI not because it is some shining example of wonderful, rather so you see how to use message() to dump your cmake variables. This is the "default debugger" when troubleshooting cmake issues.
You aren't properly using find_library()
https://cmake.org/cmake/help/latest/command/find_library.html
Had you installed the ANGLE library you built there is a 50/50 chance find_library would have found it. One would need to dump the cmake variables to see where it looked and what it found and to do that you need message().
In particular read up on CMAKE_PREFIX_PATH and the PATHS option for find_library(). If the documentation seems clear as mud you can view this SO discussion on CMAKE_PREFIX_PATH.
cmake - find_library - custom library location
The other command you need to know is ldd. It's really shocking how many people developing on Linux that don't know this command.
What ldd does, from a high conceptual level, is tell you every library the loader is going to use when running your executable, at least from an initial load standpoint. The executable itself may be able to force load other libraries at run time. When an executable dies before it starts you can use ldd to track down what library (or library used by a library) cannot be found.
In your particular case, ldd will tell you what GLES and EGL libraries were used during link. By default find_library() looks in "the usual places" first which isn't your local build directory. The problem you are running into is you are trying to replace an existing system library in your link. Here's a very detailed write-up on how to use HINTS and such with find_library().
Without being able to replicate your build environment and without a complete buildable example replicating the problem I cannot be of further help.
So I've finished my Qt application, and I need to implement testing using the Squish testing application (first time using). Apparently I require a working exe file, but I can't get the executable to run. I added all the .dll files to the same directory, only to get the error:
Prior to that I was getting errors saying that XXXX.dll is missing, but like I said, I've added them to the directory. I've tried using both debug and release builds of my project with the same results. I've also tried building a stand-alone executable, but that has it's own problems (one thing at a time). The program runs great in Qt Creator and VS2013...just not on its own.
Any solutions to this?
EDIT:
From Dependency Walker...
0x7B is the error code for invalid image format.
You're either trying to run a 64-bit application on a 32-bit system, or linking to a 64-bit library (ie you copied the wrong DLLs).
Or your binaries are just corrupted.
If you run the application standalone (i.e. not from Qt Creator) you also need the Qt library DLLs. which one you need, depends on the components you are using.
Dependency Walker is also a useful tool to find missing DLLs under Windows.
As for me it seems that something is missing. Qt on windows has the script windeployqt, it will provide all needed dependencies. See documentation http://doc.qt.io/qt-5/windows-deployment.html about use of this. On Windows you will be able to run cmd with loaded qt environment variables ( on Windows 7 see under windows applications menu - it will be available if qt is installed ). As Simon stated Dependency Walker is good tool.
I'm totally new in using Qt and I don't know a lot of stuff.
As a test I created a simple application using Visual Studio 2012 and Qt-VS-Add-in based on the newest Qt5.1
After I compiled the application it didn't work for me (gave errors), I searched all over the internet and found a lot of people saying that I have to copy those dlls mentioned below from the directory:
C:\Qt\Qt5.1.0\5.1.0\msvc2012\bin\
DLL's I had to copy to make my application work:
icudt51.dll
icuin51.dll
icuuc51.dll
libEGL.dll
libGLESv2.dll
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
My problem is the size of these dlls, they're about "37 MB" and my application itself is only "30 KB"! So, those Qt libraries will add at least 37 MB to my application [ Which I don't see it happens with other Qt-based applications I download ]. Is there any solution can make me end up with a single small .exe file?!
And I heard some people saying that I have to also include a dll for Microsoft C++ Compiler, can you explain this for me?
Note: I've come across a lot of questions here on StackOverFlow but I couldn't find anything can help me, so please do not flag this as a duplication because if I found a clear answer I wouldn't post this question!
Any help would be appreciated.
UPDATE: Use windeployqt.exe! It works really well.
http://doc.qt.io/qt-5/windows-deployment.html#the-windows-deployment-tool
The simplest way to use windeployqt is to add the bin directory of
your Qt installation (e.g. ) to the PATH variable and then
run:
windeployqt <path-to-app-binary>
UPDATE: Upon Further testing, windeployqt did not copy over all the MingW dlls for me. (Tested with Qt 5.4 on Windows 10 with MingW 4.9.1). So you need to manually get the last 3 dlls before deploying:
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll
From
C:\Qt\5.4\mingw491_32\bin
I think you may have a few extras in your list... I would double check the docs in the links below...
Here is the definitive documentation on it:
http://doc.qt.io/qt-5/windows-deployment.html
http://doc.qt.io/qt-5/windows-deployment.html#application-dependencies
Size of Qt DLLs
The amazing Qt Libraries can do a lot, but they are kind of big. Some of the older versions of Qt might be a little smaller.
For Qt 4.8 msvc QtCore4.dll is 2.5 MB, and QtGui4.dll is 8.4 MB.
How Windows Resolves Shared Libraries/Dynamic Link Libraries (DLL)
Here is how Windows tracks down a library at runtime:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Single Small EXE
If you statically link, then your EXE should grab the libraries it needs and gets built into a stand alone exe. It still may be dependent on msvc redistributables. See the next section for more info on it. But it now compiles down the .libs that you reference into your EXE and your exe no longer is pointing at other dynamically linked libraries. It does take more time to get your statically linked exe environment setup.
Your exe will certainly get bigger as it now includes the binary information for the libraries that you referenced before.
https://www.google.com/search?q=qt+static+linking
EDIT:
Statically building the exe, means that you aren't using the LGPL version.
means that you have to have your object files easy to access to end users if you are using LGPL.
I think #peppe described it well (see comment below):
Technically, you are allowed to statically link when using Qt under LGPL, even if your application is not using LGPL. The only tricky requirement is keeping the ability for a third party to relink your application against a different Qt version. But you can comply with that easily, f.i. by providing a huge object file (.o) of your application, that only needs to be linked against any Qt version.
http://blog.qt.io/blog/2009/11/30/qt-making-the-right-licensing-decision/
Look at the chart near the bottom. If you are doing the commercial version, then you can statically link, without worrying about the object files.
MSVC Redistributables
Redistributable dependencies have to do with the run-time library linker options.
http://msdn.microsoft.com/en-us/library/aa278396(v=vs.60).aspx
/MD, /ML, /MT, /LD (Use Run-Time Library)
To find these options in the development environment, click Settings on the Project menu. Then click the C/C++ tab, and click Code Generation in the Category box. See the Use Run-Time Library drop-down box.
These two links below talk about some older versions of visual studio, but the reasoning should still stand.
http://www.davidlenihan.com/2008/01/choosing_the_correct_cc_runtim.html
How do I make a fully statically linked .exe with Visual Studio Express 2005?
Hope that helps.
Just open your terminal execute your_qt_installpath/version/compiler/bin/windeployqt.exe YourApplication.exe. It will automatically copy all the required libs and stuff into the folder, where your exe is located and you can just distribute it.
For Windows you need to include qminimal.dll and qwindows.dll, you will have to put them in folder called platforms.
Even if you program is small you still call huge libraries to do the graphical interface. If the size is really important you should do a console project.
PS : You can check all the libraries you really need by opening your exe with the dependency walker.
I found another workaround without recompiling Qt again!
[ This solution may affect application execution time ]
First we need to use UPX to compress each one of Qt Libraries required by our application, they're often the dll's mentioned in the question. However, avoid compressing them too much because you'll notice that your application takes longer time to run.
[ Optional ]: If your application binary is large, you may find it useful to compress it using UPX.
After compressing all binaries, we want to get a single .exe file, so we can use
Enigma Virtual Box [ http://enigmaprotector.com/en/downloads.html ] to merge all .dll files with the main executable and we'll end up with a single tiny .exe file!
I'll just do it like this for now since I'm not able to recompile Qt with my own configurations on my current machine.
it looks to me that Qt5.2 requires fewer dll.
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
in windows you also need "qwindows.dll" in folder "platforms".
give it a try.
A possibility for reducing the size of the DLLs is by compressing them with UPX as mentioned by Alaa Alrufaie. Another method is to wrap it into an installer (e.g. Inno Setup). The latter one is particularly useful if you want to distribute it to end users). I had a simple application requiring Qt5Core.dll, Qt5Gui.dll, Qt5Widgets.dll and qwindows.dll (in the folder "platforms") taking about 17 MB. After creating a setup file, it shrank to 5 MB.
I am running in situation where I have two different versions of Qt installed, the compiled with mingw one, and the other with visual studio.
Now, When I compile my program with Qt MinGW version and run it, I got a message have scrambled text, saying that one of essential Qt modules not loaded.
My question is, how I can set the path to Qt essential modules for my application with C++. I looked at documentation and found addLibraryPath method but it seems like for Qt plugins only.
Edit
It seems I misunderstood the question, as SIFE comment that he needs to load Qt modules (like QtGui4.dll), not plugins. The answer for plugins is left here, in case it might help someone.
Plugins
Qt loads plugins that are in the SDK/plugins by default. The problem is, it finds the wrong SDK first...
If I remember right, Qt first search in the directory .. So you can copy the 'plugins' directory near your *.exe : plugins for msvc copied near the msvc-compiled exe, and plugins for gcc near gcc-compiled exe.
If you do not want to copy the plugins directory, you can use setLibraryPaths (not tested, but might work)
Last but not least, you can also use the qt.conf approach.
Modules
Modules are not dynamically loaded, in the sense that they're part of the dependencies of the application, so they are loaded at exe startup, and not via LoadLibrary. So, the solution is simple: just copy the dlls in the same folder than the one containing the *.exe
Concerning compiler, the proper library/include settings should be done by QMake.
QMake creates your makefile/VS-Project using the libraries found in the same Version Qmake belongs to.
Try calling QMake using the complete path explicitely for each Qt-Version
e.g.
c:/myQtMinGwProject>c:/Qt4_mingw/bin/qmake
c:/myQtVSProject>c:/Qt4_VS2008/bin/qmake -t vcapp
Concerning run-time, make sure the dlls for corresponding version are in PATH
I hope it helps
I believe I have too dynamically link my program. How do I link my program too QT and then install it by an nsis installer, on Windows? Do I use QMake?
Just ship your program with the Qt dll's you have used - assuming you have made no changes to the Qt source.
On linux you can assume they have the correct dlls or will get them from their distribution's repository automatically with the dependencies checker.
On windows you really need the Dlls for the same compilers so it's safer for you to include them.
If you have changed the Qt source for your own needs then you need to offer the new Qt source to any of the downloaders - otherwise just a note pointing them at qt.nokia.com would be enough.