I wish to debug an ugly crash in a C++ command-line tool. It uses, among other things, boost and crashes over there for no obvious reason. I wish to be able to debug the program in the boost source file.
The program is linked against an automatically downloaded library that has debug symbols. I'm on mac os x, The library file is located at /opt/alg/boost-1.60.0-v2-c++11/libs/libboost_program_options-mt.a. Yet the debugger of qt creator reports the source file to obey the source structure under directory /private/tmp/boost-20160422-2234-7rfp6t/boost_1_60_0, which does not exist.
In Preferences->Debugger->Source path mappings, I've set both those path to target the root directory of the source I've downloaded at /opt/alg/boost-1.60.0-v2-c++11/src, yet I still cannot see the source file and I can only see the dissambled executable.
Related
In Windows, I have a CMake build under Qt that locates, via a find_library command, an A.lib file that is in a separate directory relative to its A.dll file. The A.lib file is then linked using a target_link_libraries command.
As far as the build goes, CMake has no problem not having the symbols in the .lib file defined until runtime.
At runtime, I use windeployqt to successfully assemble all dependent libraries (indluding the A.dll file) into a separate deploy directory from the build directory, and I'm able to run there just fine.
However, to run via Qt's debugger, Qt runs the executable from the build folder rather than the deploy folder. By default, Qt attempts to add the build library folders to the PATH variable as well. Admirably, it also attempts to scan dependencies such as the Qt libraries and the path to A.lib and adds them to the PATH as well. Unfortunately, it does not add the path to A.dll, resulting in a failed DLL dependency error in the launched thread.
I can easily get around this by adding the path to A.dll to the PATH in Qt's run section of the Project tab. However, I'm curious, is it possible to make Qt catch this dependency via some CMake command and automatically add A.dll to the PATH, similar to how it caught other dependencies correctly? I'm not sure how Qt attempts to find dependencies, but in a previous QMake iteration of the build, the path to A.dll was appended automatically.
As of Qt 7.0.1, Qt added a workaround that allows the user to add dll paths to CMake via a target_link_directories command and have those parsed by Qt from the Cmake file-api to add to the PATH variable in Windows.
This fix is in Qt Creator 7.0.1, see the change summary here:
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/404290
And the issue prompting this change on the official Qt website (which is where I should've looked first):
https://bugreports.qt.io/browse/QTCREATORBUG-27201?workflowName=Qt+Bug+Tracking+v2.4&stepId=8
It should be noted that a workaround for this issue was added to Qt Creator at an earlier point (I'm not sure exactly when) that looked one directory above the \lib folder for a \bin folder (see the code that implements this workaround, and performs the CMake file-api queries in general here).
The latter workaround happened to not work for my particular MSVC-built library folders, since there the lib and bin folders are themselves in folders with architecture and OS information, with a common parent three and two folders above, respectively.
Updating Qt Creator to 7.0.1 and using the target_link_directories command solves this issue.
I am developing a plugin for a third-party host application on MacOS that compiles as a .dylib (with associated DSYM directory). The .dylib and DSYM directory is automatically copied to the host's plugin directory by a supplied build script. The build script uses clang to build the .dylib. The host application is able to open the plugin.
With Xcode, I am able to debug the .dylib with lldb within Xcode, because Xcode is somehow able to identify that the sources match the dylib once it is loaded.
I wish to set up a similar system with CLion, however I have not been able to get CLion to associate the breakpoint lines in the source with the dylib. When I create a breakpoint in the source it warns me that "Breakpoint will not currently be hit. No executable code is associated with this line". I almost expect this kind of warning because the image hasn't been loaded into the host application yet. However loading the plugin does not trigger the breakpoints.
I tried setting the Configuration's Executable to the .dylib, and setting the working directory to the location of the .dylib and the DSYM directory (this is what I have to do when running lldb manually), and this does not seem to help.
My questions are:
Does CLion use lldb internally?
Is what I am trying to do possible with CLion?
If so, what is the correct configuration for this situation?
One important thing to note is that I am not building the .dylib with CLion directly, it is build by an external build system, I am just trying to debug the resulting image with CLion, which I understand should work (it works with Xcode & lldb at least). I have a basic CMakeLists.txt that is sufficient for CLion to understand the code base, but it is not used to build it (beyond any background compilation that CLion might do to check syntax etc).
I'm building a program Using Qt Creator 5.2.1 (32 bit) with Mingw. One of the dependencies of this program is the libcurl library.
QT was building the file properly, however, when running, it would throw an error 139.
After running the dependency walker on the binary, I noticed that the libcurl dll in turn depends upon another dll called "libeay32.dll".
I did the following:
Copied the my program along with all required libraries(including
libeay32.dll) externally to Qt and ran it (this was successful).
After that I tried running from within QT, but having the libeay32 library in the build before running (this was successful)
Logically, I presumed afterward, that if I put the path to the libeay32 prior to any other paths within my PATH variable, that It would pull the correct version of the lib (re: answer to question here). However this did not work, throwing the same error 139 (it's apparently not finding the library)
I know I could run and test my program by simply copying the file into my working directory, however, for information purposes, I was wondering;
Is there any way of doing this without having to copy this DLL?
My instinct would have been that fixing the Path to point to this firstly would have helped as this would ensure that the DLL is pulled used before any other occurrences that may be there in other dirs.
Note: In referring to the PATH variable, I mean both the SYSTEM path and checking for the PATH Qt uses (Qt adds a few dirs to the path)
Thanks in advance for any help.
Either you link static, or you have to ensure that your library is located in one of the following locations (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications):
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
I want to use Qt in my new project. An installer for my target compiler (VS2010 64bit), does not exist.
I am using Windows 7 64-bit with Qt 5.1.1.
A colleague of mine is also planning on using Qt and has managed to compile it for my target compiler (which he uses as well). He has built it in some directory, say DirA. He graciously gives me a copy of his entire Qt SDK build (binaries, examples, headers, and all), and I copy it to DirB on my machine.
I need it in DirB, because that is where all my 3rd party libraries are installed, and my CMake scripts know how to find them. I also added the Qt bin folder to my path.
Problems ensue. Qt binaries for some reason have the install path (in this case the build path) hard coded within them. So even though the Qt bin folder is in my path (so DLLs are found), Qt's DLL(s) are looking in the wrong place for the windows "plugin". They are looking in DirA, which does not exist on my machine.
So from what I found researching, using a qt.conf file specifying the install path root, is supposed to be the way to go. I add one to my Qt bin dir, and now Qt binaries (assistant, qmake, etc) can run.
But now I build one of the examples. Builds fine. Run the exe, Qt DLLs load, and then it crashes because it can't find plugin directory.
A work-around my colleague and I found that seems to work, is to copy my qt.conf file to the directory my exe resides in. After doing that the exe runs.
But this does not seem right. My exe can find the Qt DLLs, but the Qt DLLs it loads can't find qt.conf. They don't know to look in their own containing folder. I must have qt.conf in my working directory (my exe dir) for it to be found and used.
Does anyone know why this might be happening, and know of a way for me not to be forced to have a qt.conf file in my exe's dir? I can't accept this requires a rebuild of Qt. There must be some other way.
You can put qt.conf into your binary. Using the resource system.
From the Qt docs:
Without qt.conf, the Qt libraries will use the hard-coded paths to
look for plugins, translations, and so on. These paths may not exist
on the target system, or they may not be accesssible. Because of this,
you need qt.conf to make the Qt libraries look elsewhere.
QLibraryInfo will load qt.conf from one of the following locations:
:/qt/etc/qt.conf using the resource system
Or:
Using QApplication::addLibraryPath() or
QApplication::setLibraryPaths(). This approach is recommended if you
only have one executable that will use the plugin.
If you add a custom path using QApplication::addLibraryPath it could look like this:
qApp->addLibraryPath("C:/customPath/plugins");
I just installed QT 4.6 on snow leopard 10.6.3. I wrote a really simple program. I can generate a xcode project using qmake, but I can't step into QT function. How can I set it up?
By default, qt is built with a debug and a non-debug library. This is my understanding. For example,
% ls /Library/Frameworks/QtCore.framework/
Contents/ Headers# QtCore# QtCore.prl QtCore_debug# QtCore_debug.dSYM/ QtCore_debug.prl Versions/
Also, my default from source build of Qt 4.7 branch also has the *_debug libs.
Setting up for Xcode is cake, you just set up your project and
% qmake -spec macx-xcode
This -spec is the default for the official mac distribution, but if you build your own from source the default is macx-g++ which creates a Makefile project.
This generates a MyProject.xcodeproj that comes preconfigured to link all the necessary Qt frameworks, sets up paths, and has a Release and Debug build target set to the same options as the official SDK's.
This is all assuming you have your qt project file set up, if you need to generate that first from a raw source directory:
% qmake -project
Debugging works "out of the box" for these generated *.xcodeproj files. However, there's one little "hitch". Since Qt is full of custom data types, Xcode doesn't know how to display their "values" in the debugger's summary pane. So you can't see what value a QString has, for example.
There's a method of entering custom macros for display, but I've found these often (always?) don't work for QObjects.
To get that working, I've started a project that uses xcode's debugger c callbacks (also mentioned in the above linked article, though their example doesn't even work o.O). I call it Qt4DataFormatters.
I've just started it and have been adding types as the need arises. It's dirt simple to create one using the existing functions as a template though.
I haven't tried this on Mac, but on Linux you need to take the following process:
First, you need to setup Qt so that it has debugging symbols available to you:
./configure -debug-and-release separate-debug-info # other options
With the debugging symbols available, you should now be able to get valid stack traces.
When building your application with qmake, you need to have the debug (or debug_and_release) flag set in your project file:
CONFIG += debug
Once you've done that, you should only need to tell the debugger where the Qt source is located:
(gdb) dir /path/to/qt/src
After that, list should show you the actual Qt source code. You may need to add additional directories under the src directory for the debugger to pick it all up.