I am generating code coverage data files (.gdca and .gcno) on an iOS project running on Xcode 4.5 using Apple LLVM Compiler 4.1.
Files are being generated under Library/Developer/Xcode/DerivedData/viewer-evgaabclrjcouydwveuptwroeofm/Build/Intermediates/viewer.build/Coverage-iphonesimulator/viewer_generic/viewer_generic.build/Objects-normal/i386.
All the (.o, .d, .dia, .gcda, .gdno) files are under this directory. There are no sub folders.
I am able to open individual .gcda files using Cover Story. Now I want to generate a report which can be viewed using cobertura.
I am trying to use gcovr for this. On terminal I got to the above folder
Command: gcovr -r `pwd` -x -v
Output:
(Several lines of similar output as below)
Running gcov: 'gcov /Users/abc/Library/Developer/Xcode/DerivedData/viewer-evgaabclrjcouydwveuptwroeofm/Build/Intermediates/viewer.build/Coverage-iphonesimulator/viewer_generic/viewer_generic.build/Objects-normal/i386/FILE_NAME.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /Users/abc/Library/Developer/Xcode/DerivedData/viewer-evgaabclrjcouydwveuptwroeofm/Build/Intermediates/viewer.build/Coverage-iphonesimulator/viewer_generic/viewer_generic.build/Objects-normal/i386' in '/Users/abc/Library/Developer/Xcode/DerivedData/viewer-evgaabclrjcouydwveuptwroeofm/Build/Intermediates/viewer.build/Coverage-iphonesimulator/viewer_generic/viewer_generic.build/Objects-normal/i386'
Parsing coverage data for file /Users/abc/Documents/Perforce/DPS-MacBookPro/depot/sandbox/Viewer-Labatt/Blue/viewers/ipadviewer/iphone/apps/viewer/Classes/view/zooming/FILE_NAME.mm
Filtering coverage data for file /Users/abc/Documents/Perforce/DPS-MacBookPro/depot/sandbox/Viewer-Labatt/Blue/viewers/ipadviewer/iphone/apps/viewer/Classes/view/zooming/FILE_NAME.mm
Gathered coveraged data for 0 files
<?xml version="1.0" ?>
<!DOCTYPE coverage
SYSTEM 'http://cobertura.sourceforge.net/xml/coverage-03.dtd'>
<coverage branch-rate="0.0" line-rate="0.0" timestamp="1354144430" version="gcovr 2.4 (r2774)">
<sources>
<source>
/Users/abc/Library/Developer/Xcode/DerivedData/viewer-evgaabclrjcouydwveuptwroeofm/Build/Intermediates/viewer.build/Coverage-iphonesimulator/viewer_generic/viewer_generic.build/Objects-normal/i386
</source>
</sources>
<packages/>
</coverage>
I am seeing a warning: gcno:version '404', prefer '402'
Please help me figure out why gcovr is unable to produce the report.
Tl;dr: The code coverage files that LLVM outputs are newer than the ones expected by gcovr. If you replace your version of gcovr with the linked version (version 2.4), then it should work. Maybe.
Back before LLVM, Xcode used GCC as its compiler. GCC included a tool called 'gcov', which generated all those files, .gcno, .gcda and their ilk.
Back then, Macs came preinstalled (and still do) with GCC version 4.2. So Xcode would compile your project with gcc 4.2, and then run gcov version 4.2, which would generate 4.2-versioned test coverage files. This worked fine for gcovr, because the pre-2.0 alpha version seems to have been written with gcov 4.2 in mind.
But when Apple switched to LLVM, things went squirrely. LLVM also outputs gcov-style test coverage files, if you set the 'Generate Test Coverage Files' flag in your target settings. BUT, LLVM defaults to outputting gcov 4.4 files, NOT 4.2.
This person had the idea that if we could tell LLVM to output the 4.2 version of the files (I think it may technically be able to), then it would solve the problem. That's probably true, but I don't know how to do that.
I did however, find a solution for myself. I opened up terminal, and checked my version of gcovr:
gcovr --version
It told me that my version of gcovr was actually gcovr 2.0-prerelease. This version doesn't support the gcov 4.4 versions of the test coverage files.
So I found a version that does.
Here's the page where it is hosted: https://software.sandia.gov/trac/fast/wiki/gcovr
And here is the link to the script itself: https://software.sandia.gov/trac/fast/export/2800/gcovr/trunk/scripts/gcovr
This script is gcovr 2.4, which supports up to gcc 4.8. Theoretically, it should be quite happy with the 4.4 versions of the test coverage files that LLVM outputs. That warning is now completely gone for me. Give it a shot, let me know how it goes!
Are you properly specifying the your object directory path? According to the gcovr documentation
--object-directory=OBJDIR: Specify the directory that contains the gcov data files. gcovr must be able to identify the path between the *.gcda files and the directory where gcc was originally run. Normally, gcovr can guess correctly. This option overrides gcovr's normal path detection and can specify either the path from gcc to the gcda file (i.e. what was passed to gcc's '-o' option), or the path from the gcda file to gcc's original working directory.
The following command works for me when run under the root directory of your project.
gcovr -r . --object-directory path_to_coverage_files -x > coverage.xml
Where the path_to_coverage_files is the directory where all your (.o, .d, .dia, .gcda, .gdno) files are.
Related
I wrote a demo using libpq to connect to a PostgreSQL database.
I tried to connect the C file to PostgreSQL by including
#include <libpq-fe.h>
after I added the paths into system variables I:\Program Files\PostgreSQL\12\lib as well as to I:\Program Files\PostgreSQL\12\include and compiled with this command:
gcc -Wall -Wextra -m64 -I "I:\Program Files\PostgreSQL\12\include" -L "I:\Program Files\PostgreSQL\12\lib" testpsql.c -lpq -o testpsql
It first raised three errors, like
libssl-1_1-x64.dll is missing
libintl-8.dll was missing
libcrypto-1_1-x64.dll was missing
After I downloaded these three files and put them into I:\Program Files\PostgreSQL\12\lib, and compiled it again, it shows the error
The application was unable to start correctly (0xc0150002)
when I type testpsql. But if I type ./testpsql on git bash, it works. Anyone can please tell me why?
The code that I used was the first example from here.
Environment: PostgreSQL 12, Windows 10, MinGW64
“Download the DLL files” sounds dangerous. From where?
I would get rid of these files again. Since you probably don't reference these libraries from your code, it must be the dependencies of libpq.dll and are probably found in I:\Program Files\PostgreSQL\12\bin (if you used the EDB installer).
The problem is probably that you the PATH environment variable is different in git bash and in cmd.exe, and in the latter case not all required shared libraries can be found on the PATH. The solution is to change the PATH so that it includes all DLL files the executable requires, not to start copying around files.
It is probably enough to include I:\Program Files\PostgreSQL\12\bin in the PATH. To resolve missing dependencies, use a tool like dependency walker or this replacement.
The program I want to profile with gcovr (or gcov/lcov) is located on a shared filesystem, along with the build directory from compiling the program, and I have multiple workers with which I intend to test my program, in parallel. To solve the race condition problem (the workers will all run my program, therefore all generating gcda files, named the same, in the same location on the shared filesystem), I redirect the gcda files to a separate target directory on each worker (as described here), and I have been running the following command:
gcovr -v -r /absolute/path/to/root --html --html-details -o test-details.html --object-directory=/absolute/path/to/object/dir /absolute/path/to/gcda/dir
where the last path is the search_paths, described here. I expected this to look in /absolute/path/to/root for the program source, /absolute/path/to/object/dir for the .o files, and /absolute/path/to/gcda/dir for the gcda files. However, I ran it with -v and I'm seeing that gcovr is running gcov commands in the form of this, from the root dir:
gcov /absolute/path/to/gcda/dir/file.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /absolute/path/to/gcda/dir
Again, I expected it to run in the form of this (look at the --object-directory path):
gcov /absolute/path/to/gcda/dir/file.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /absolute/path/to/object/dir
It behaves properly when run like the latter command, but gcovr is running the former. I'm only using gcovr instead of gcov because I have a large project (I know gcovr is built off of lcov). Does anyone know why it is behaving like this? (Is this the way it is supposed to run?) How can I make it so it behaves the way I want? Thanks in advance!
This was cross-posted to the gcovr issue tracker on GitHub, here's the summary:
Gcovr currently expects that the .gcda and .gcno files are right next to each other (which is usually the case). The search paths affect where gcovr searches for these files. The --object-directory only provides a default value for the search paths, but here you have overridden that with an explicit search path. The gcovr --object-directory option is not passed through to the gcov --object-directory option.
As of gcovr 4.1 there is no option to solve this. You will have to copy the .gcno files from the build directory into each directory with coverage data. Alternatively you can run gcov manually and then aggregate the .gcov files with gcovr -g ....
Additional notes:
gcov is not interested in the .o object files, only the .gcda files (written during test execution) and the .gcno files (written during compilation).
gcovr and lcov are not directly related
I have a Windows 7 64bit system with the latest MinGW (32bit) installed along with the Qt 5.5 SDK (again 32bit) which also ships with its own MinGW. Due to the fact that I'm not the only one using the system I can't remove the standalone MinGW.
My project is using qmake and is a plain C project (not C++). Everything builds fine but when I try to execute my binary in the command line I get that the application was unable to start due to a missing libgcc_s_dw2-1.dll on the system.
After looking into the issue I found that both the standalone MinGW and the one shipped alongside the Qt SDK have the mentioned DLL.
Standalone MinGW - libgcc_s_dw2-1.dll is located inside the bin subdirectory of the MinGW installation where the binaries are located (gcc, g++, gdb etc.)
Qt MinGW - libgcc_s_dw2-1.dll is located inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\lib subdirectory while the MinGW components' binaries are inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\bin.
I would like to know how to properly set my PATH variable so that:
The application starts properly
No conflicts with the standalone MinGW installation occur
Just a side-note: I've already checked other posts here on SO but was unable to find a solution (perhaps I've missed it). I have also tried LIBS += -static but the result is the same.
You just need to copy this dll with your executable, i.e.:
cp <path-to-qt-install-dir>\qt5.7.0\5.7\mingw53_32\bin\libgcc_s_dw2-1.dll <path-to-dest-dir>
You mat find that you have other dependencies, to see which other deps you have you can use: ldd <your-executable>. You only need to copy the qt specific dlls you can see these by:
ldd <executable> | grep -i qt
note
You can statically link it with:
linker commands like -static-libgcc or -static, but I think you start to hit LGPL issues and also you may need to statically compile qt from source - can't recall for this particular file.
note2
Sorry ldd is for linux, just realized you have windows, in which case you can use one or both of:
dependency walker: from here
<path-to-qt-bin-folder>\windeployqt.exe <path-to-your-executable>
I have mixed results with windeployqt, but if you have any plugins its quiet good for getting that part sorted.
I have successfully set up gcov in my project to generate HTML files with code coverage data using lcov. However, as I often work via SSH with a text console only, I'm looking for a way to generate annotated source files like git-blame does with the history:
covered source_line();
not covered other_source_line();
Is it possible somehow?
I'm going to assume you are referring to gcovr when you say gcov, since gcov does not output to HTML format. gcovr does output to HTML though. gcovr is basically just a wrapper for gcov.
In order to get the annotated source files, you need to simply use gcov.
gcov, by default, annotates source files.
To run with gcov, you just need to compile with -fprofile-arcs -ftest-coverage -fPIC -O0, and link in the gcov library(-lgcov).
Then run your program.
Then issue the following command:
gcov main.c
Where main.c is whatever file you want your annotated analysis on.
After that, you will notice a new file created(main.c.gcov). This is the file you are looking for.
Here's a link on gcov usage
I'm working to compile the Thrift 0.9.0 binary statically in a CentOS VM. I get the issue that the libthrift.a binary is not being created. I am using a vagrant box to run centos:
https://github.com/2creatives/vagrant-centos/releases/download/v6.5.1/centos65-x86_64-20131205.box
Once I ssh to the vagrant box I run the following commands:
wget https://archive.apache.org/dist/thrift/0.9.0/thrift-0.9.0.tar.gz
tar -zxvf thrift-0.9.0.tar.gz
cd thrift-0.9.0
./configure --enable-static
make
This will run but I ran a find command (sudo find / -name "*.a") on the system to see if there was any ".a" files made and the only file that was made was "libparse.a" which doesn't seem right. From my understanding it should be "libthrift.a".
Searching through the config.log file it says that it does want to build the static libraries:
configure:11944: checking whether to build static libraries
configure:11948: result: yes
Looking at more locations in the log file that has the keyword "static" reveals potential places that may be errors.
configure:9028: checking if gcc static flag -static works
configure:9056: result: no
configure:13915: checking if g++ static flag -static works
configure:13943: result: no
lt_cv_prog_compiler_static_works=no
lt_cv_prog_compiler_static_works_CXX=no
The full log file is here: http://www.filehosting.org/file/details/449460/staticThriftErrorLog.rtf
Any help is appreciated
I was able to generate the libthrift.a file. After running the command for the extra dependancies mentioned in my comment I forgot to run the make command. So after doing the make command I found the libthrift.a file in "thrift-0.9.0/lib/cpp/.libs/". Interestingly enough, even after fixing the dependencies, config.log still had the same potential problem areas regarding the gcc/g++ static flag and static compiler.
Specifically the dependency command is as follows:
sudo yum install automake libtool flex bison pkgconfig gcc-c++ boost-devel libevent-devel zlib-devel python-devel ruby-devel openssl-devel.x86_64
Edit: After getting advice on the Jira ticket, it turns out the specific vagrant box I was using was causing the errors. Using the VM he linked I was able to successfully build Thrift using the provided instructions. (Jira ticket https://issues.apache.org/jira/browse/THRIFT-2559)