We're using QtCreator 3.2.1 to analyse core dumps on Linux (Debian Jessie). Currently we load it up manually via the menu and "Load Core File" dialog, which allows us to specify a GDB startup script which we use to set up the source code search paths. The paths, and hence the startup script, depend on the specific build being debugged, and so need to be specified along with the executable and core file.
It would be convenient to be able to launch this from the command line via a small Bash helper script. Unfortunately, while QtCreator has command-line options to specify the core file and executable, it doesn't appear to have one to specify the debugger startup script.
Is there some alternative?
Just a crazy idea:
Create a wrapper $HOME/mygdb/gdb:
#!/bin/bash
gdb -command="${$HOME}/mygdb/.gdbinit" "$#"
Then invoke QtCreator like this:
PATH=$HOME/mygdb:$PATH qtcreator -debug myexecutable,core=mycorefile
Inspired by #DBedrenko's initial comment, we configured the GDB Debugger with an Additional Startup Command of source startup.gdb.
The bash helper script simply cd's to a directory containing the appropriate startup.gdb file, and invokes qtcreator -debug <exe>,core=<core>.
Works nicely.
Related
Scenario:
I am have a Qt App with a QtApp.pro some C++ code in main.cpp. To keep this question simple, please assume that it is a blank QtQuick2 app created from the QtCreator Application wizard.
Question:
Is it possible to run some Qt commands in the .pro files or C++ code in main.cpp?
What if I want to run this git command git rev-parse HEAD from my QtApp.pro or main.cpp and embed the commit ID somewhere on my UI to show the commit ID of the release? Is it possible? How?
Environment:
The Qt version I am running is Qt 5.9.3
Operating System : MacOS High Sierra
Is it possible to embed the command in pro file and access the pro file variable into an std::string?
To run command in pro file, this post, Running a program/script from QMake, shows you how to run script in .pro. I think you can write your git command in that script.
To access the pro file variable into an std::string.
you can transfer the file variable by -D option of gcc, which you can define it with QMAKE_CFLAGS in .pro file. this post, How to define a string literal in gcc command line? shows you how to use -D option.
You need to think separately of build time (includes compile-time) and run time. In general (think of some cross-compilation scenario, or just of a Qt application deployed on other computers) that could happen on different machines and on different days.
At run time, you could use QProcess to run some git command (or whatever program or script you need to run). Of course, you need git to be installed, and perhaps your source code tree to be available at run time (on a deployed and installed Qt application, that might not be the case by default; for example most Qt applications on my Linux distribution are not installed with their source code tree).
At build time, on Unix-like machines, a .pro Qt project file is generating a Makefile which is used by make for build. That Makefile could contain git commands. See _timestamp.c target of this Makefile (not using Qt so hand-written, not generated by qmake) as an example; it contains details about the current git commit.
How to configure qmake to generate custom commands in the Makefile is a different question; you might add custom targets.
I have a CMake project in CLion. I am able to build my executable hello.
Now I want to run it inside CLion with a custom runner mpirun (it is an MPI project).
Bash command should look like: mpirun -n 5 path_to_hello_executabe/hello
How can I obtain this path_to_hello_executabe inside CLion configuration?
In CMake it looks like add_custom_target(run $ENV{MPIRUN} -n 5 $<TARGET_FILE:hello>), so what I need is an equivalent for $<TARGET_FILE:hello>.
Configure build output path in Build, Execution, Deployment | CMake settings. So you know the path_to_hello_executabe now.
Add custom command in your CMake that will be executed during build. Then build the corresponding configuration in CLion. Your command will be called then.
That's not possible for now in CLion, since CLion's configurations can't run a command from add_custom_target cmake command. However this looks like an interesting use case and a nice feature to have: https://youtrack.jetbrains.com/issue/CPP-5831
I am working on a requirement to do instrumented build for c++ code on coverity(static code analysis tool, version 7.5.1) build server via command line. Need to execute a basic c++ code via command line, I tried using the cov-build command cov-build –-dir cov-int cl /c test.cpp and various other permutations on the directory where coverity is actually installed in the build machine. But there is some problem. System can understand only the cov-buld --dir and if i use only this command along with /c, this file opens in visual studio rather than giving the% of compilation units.
Please help me if anyone have done this before.
First be clear with your requirements. Which system you are working on?(windows or Mac or Unix or Solaris). Before starting cov-build, configure the compiler which will execute the source file. As you said you are working on C++ source code, use GCC compiler to configure with Coverity Static Analyzer. Coverity Directly supports for 3 Compilers(Gcc and 2 more). To configure this GCC use cov-configure command followed by gcc.
Then use cov-build command to analyze.
Sample command is:
path_to_cov_bin/cov-build --dir path_to_output_folder gcc hi.cpp
It will create emit folder with emit-db in path_to_output_folder. Then cov-analyze command will be analyze that emit folder and create Output Directory in given path.
To compile N number of source files use makefile. If you have any query about makefile You can put a post here or refer in this site.
I am trying to use GDB to debug a C++ program, but my system is not recognizing gdb as a command. I installed it, along with many other tools, via MinGW. I have not had any problem with the other features I have used (gcc, g++), so the issue doesn't seem to be with my general set up. I have added the MinGW\bin directory to my PATH. The gdb.exe is in that folder. But it will not run when invoked from my project directory, it simply errors: "'gdb' is not recognized as an internal or external command, operable program, or batch file." Is there some step in setup or invocation that I missed for using GDB?
EDIT: Alright, I think I found the problem: there are two MinGW directories in my PATH, one at C:\MinGW, and another in folder that got installed with some Haskell compilers I used a while ago. It appears to be defaulting to the Haskell folder, perhaps because this directory is listed first. However, this folder contains gcc and g++, but NOT gdb. I was able to get the gdb command working by creating the fstab file in the msys directory, a step I apparently forgot when setting up MinGW. I added my C:\MinGW directory to it, and now the gdb command is working properly! Out of curiosity, what does this file do?
Also, ideally I would like it to look in the C:\MinGW directory first, since this is the folder I plan to keep updated, and the one that contains ALL of the various applications. However, the Haskell directory is specified via the system PATH variable, which I've read it's not a good idea to touch. Would switching the order that they appear even fix my problem?
EDIT 2: Not 100% sure what happened, but the gdb command appears to be working now. I have always been using the Windows cmd prompt to run these tools, so per the answer below (that I should not need to mess with msys) I deleted the fstab file, and lo, it still works! However, my second question above still stands: What is the best way to get the compilers to run out of C:\MinGW\bin instead of C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin? Is moving the Haskell location out of the system PATH and to the end of the user PATH a viable option?
I had to run pacman -S mingw-w64-x86_64-gdb separately and then gdb showed up in the bin.
You do not have to run gdb (or gcc and all other MinGW tools for that matter) within msys - it is not like Cygwin in that respect. Had you run it from the Windows cmd console, it should work.
The msys shell is useful for running configure scripts generated by Autoconf used by many Linux originated open source projects, but its environment is independent of the Windows environment.
Why do I get the following when running ocaml interactively under tuareg 2.05?
OCaml version 4.01.0
Cannot find file topfind.
Unknown directive `camlp4o'.
I'm using OSX 10.9.
Iain
It looks like you have a .ocamlinit that tries to load topfind, which is failing because you do not have the right directory in the search path.
If I had to hazard a guess, I'd say that you've put some configuration junk (maybe something like eval `opam config env`) in a configuration file such as ~/.bashrc that arranges for this to work in the shell, but emacs doesn't get to see it because .bashrc is not consulted by the desktop environment in which you start emacs. Does running ocaml under bash in the same directory work and successfully load topfind? If so, find which configuration files your environment does consult and move the relevant code into one of those. ~/.profile, maybe.