I have an c++ application developed using gcc(4.1) and compiled with CMAKE MakeFiles . The Code is large in size and debugging it is tough. I dont know how to debug the code line by line using cmake Utility. Any idea how to do it?
Thanks in advance :) .
CMake is a system to enhance the definition of makefiles (it is a meta system that creates platform specific makefiles). It is not a debugger. You can use gdb for debugging.
To ensure your program is compiled for debugging properly, make sure the flags passed to gcc include -O0, which means no-optimizations, and -g for debugging information,
or -ggdb to produce a format that suits gdb really well (see also http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html).
Related
I just installed YCM on CentOS 7. I am now at the step of generating a ".ycm_extra_conf.py" equivalent of the file for my project, which is a nested directory of c++ files, uses Scons build system and g++ (with -std=c++98) to compile the c++ files.
I have few questions:
Are the contents of the "flags" variable in ".ycm_extra_conf.py"
file the flags that are passed to the project compiler, in my case
the g++ compiler by the scons build system?
If answer to question 1 is yes, are these same flags then passed to
clang when YCM compiles the files? If so, is YCM compiling or more
technically processing the c++ files in the project to use for
semantic completion?
If answer to question 2 is yes, then I am guessing the flags I state in
the "flags" variable will not work for clang, as they are applicable to
g++. Should I do a conversion/mapping of the flags to clang?
Does YCM use clang to only front-end compile the files to produce the
AST to use for semantic completion?
Sorry about the naive questions, I am very new to YCM. Any help/guidance would be very appreciated.
Regards and thank you,
Ahmed.
The easiest way to get autocompletion working in vim with ycm is bear:
https://github.com/rizsotto/Bear
Install it and then just run:
bear scons
and you'll get your compilation database that makes ycm happy.
I've been working on adding functionality to a C++ library. The library is compiled by using CMake. It has a complex set of dependencies. I have a C++ test file that runs code relating to the library. Let the compiled file be test.cpp, its executable test.
So far, I've been debugging by adding "cout" statements to the library files. I frequently get segmentation faults, but can usually figure it out by inspection. Obviously, this is inefficient. I want to see where the code fails, by using gdb. Via this stackoverflow post, I tried adding debug flags to my cmake, but when I run gdb on test and do bt, I don't get comprehensive info. I simply get the name of the function in the library where the code fails, not the exact line.
Anyone know how to get the gdb information?
While adding the respective compiler flags manually will work, it is not the most convenient way of doing so. As suggested by #ruslo, you should use the following command line instead for getting debug support:
cmake -DCMAKE_BUILD_TYPE=Debug <path_to_source>
There are several reasons for this:
Compiler flags are not portable. -g -O0 will work on gcc, but what about other compilers? One of CMake's main strengths is to make portability easy, so you should not throw it out of the window easily.
Multi-configuration generators (like most IDE generators) allow to use multiple profiles at once. You would not want to force users of those IDEs to compile without optimizations even though they selected a Release profile, would you?
Changes to CMAKE_CXX_FLAGS are global. This becomes especially nasty once you have to compose multiple projects together. If you absolutely need to manually give compiler flags, use target_compile_options for this purpose.
Last but not least: Setting CMAKE_BUILD_TYPE is the idiomatic solution to this problem. It is the one right tool for solving it and people familiar with CMake (granted, there are not too many around of those...) will be surprised if you solve it using a non-idiomatic workaround.
I've figured it out. They key is to add the "-g" flag to
SET (CMAKE_C_FLAGS ...
and
SET(CMAKE_CXX_FLAGS ...
to the CMakeLists.txt file.
I am trying to compile my project for use of debugging with gprof; however, I am having numerous issues.
Right now, I am trying to create a separate target in my makefile that is 'gprof' which depends upon the executable. This target, beforehand, adds the flags -g -gdwarf-3 and -pg to the compilation flags and -pg to the linker flags.
The unfortunate thing is I cannot get gprof to run successfully, as my compiled binary doesn't produce the required gmon.out. There are also side issues regarding this process.
1.) I am getting an issue regarding a clang warning when trying to introduce gdwarf-3 flags. This issue is clang: warning: argument unused during compilation: '-gdwarf-3'.
2.) The makefiles (3 of them, one main, one more main executable, and one for linked library) were produced by premake. I have edited them to introduce compiler and linker flags.
3.) I don't know how to compile the linked library (vecmath) under gprof (do I even need to?). The ar command doesn't accept the necessary -pg flag needed for gprof.
I am trying to perform this on a macbook air 2011, MAC OSX 10.8. I will try to attempt this later in linux.
My three makefiles are shared here. Makefile calls a5.make and vecmath_makefile (this file title was edited). Any help is appreciated thanks!
I know how to use g++ and all that to compile c++ programs.
My question is, if I have some code which depends on various libraries, how can I compile it into a simple executable that I can send anyone. For this I would be happy with just keeping it on os x.
I would like to know how to compile a "real" program not just an executable I can run locally.
I have tried googling this but haven't found much.
Do I have to use installing software?
I know in windows you can make some simple .exe stuff that use common DLL files.
You a looking for "static linking". That will import all the needed code from the libraries into your executable. Note the executable will get larger. If you are using standard libraries, they should be present on standard OS installation.
You should try "-static" flag of g++.
Running "ldd your_executable_name" should display all libraries your executable uses (linked dynamically).
Since you are talking about Mac OS X, you probably want to make a bundle. Qt Software has a very useful deployment guide for getting started with this kind of activity.
You can use -static or -s option for static linking in gcc or g++
I am a beginner in GDB and I got it working correctly. However, I am wondering how this is used in big projects. I have a project where build is done using makefile and g++. For GDB to work, we need to compile with debug symbols on, right (g++ -g files)?
Question
Do I need to create a new target in makefile something like "debug", so that I can make a debug build like make debug. Is this the best practice?
Suppose, I need to debug only foo.cpp and is it possible to generate debug symbols only for that other than building whole program including main?
Any thoughts?
Not needed, although you may want to consider always building with -g (sometimes, you may even need to try and debug optimized (-O1, -O2, etc) code; why not leave -g on? For releases, you can always just run strip on the binary.
Yes. Build just that file with -g .
I don't think there is a big difference between the usage of gdb in big, medium or small projects. However, for big projects you must consider the amount of space required for the build, because the debugging info increases the size of the object and executable files.
If you initially underestimate the need for debugging of the whole solution you will likely suffer from your decision in the future. It is always good when the build could be done with or without debugging information, so write your build scripts carefully.
Yes, but consider my previous answer. Sometimes the problem could be coming from a module for which you don't have debugging info.
In big projects here where I work we always build with most verbose debugging info possible (like, '-ggdb3' for native gdb format or '-gdwarf-2 -g3' for access to macros in gdb).
When we're done with debugging, we just use 'strip' command to strip all debugging info from the binaries.
gcc -ggdb3 blah.c -o blah
strip blah
gdb will work without the symbols; it's just that the output is much less useful then.
It's a matter of preference. I build everything by default in debug mode, and do make release when necessary.
Yes.
You can always have the debug version's saved somewhere, and if you ever need to re-bind the symbol info, after your debugging the stripped/release version, you can just go "file /path" and gdb will re-read the symbols for that target. Also you can use "symbol-file /path" to configure symbol information to be bound to a stripped file.