I have two folder inside same folder as below :-
1.src (it contains my cpp file)
2.linux (where I am running g++ and executing o file)
now I am running commands as below
cd linux
g++ --coverage ../src/example1.cpp -o example1
./example1
cd ..
/opt/gcovr-3.2//scripts/gcovr -v -r .
I got output as, with 0% coverage
Scanning directory . for gcda/gcno files...
Found 2 files (and will process 1)
Running gcov: 'gcov /opt/gcovr-3.2/doc/examples/example1/linux/example1.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /opt/gcovr-3.2/doc/examples/example1/linux' in '/opt/gcovr-3.2/doc/examples/example1/linux'
Parsing coverage data for file /opt/gcovr-3.2/doc/examples/src/example1.cpp
Filtering coverage data for file /opt/gcovr-3.2/doc/examples/src/example1.cpp
Gathered coveraged data for 0 files
To debug further, I goto 'linux' folder as run below command
gcov /opt/gcovr-3.2/doc/examples/example1/linux/example1.gcno --branch-counts --branch-probabilities --preserve-paths --object-directory /opt/gcovr-3.2/doc/examples/example1/linux
I got output as, with valid coverage
/opt/gcovr-3.2/doc/examples/example1/linux
File '../src/example1.cpp'
Lines executed:85.71% of 7
Branches executed:100.00% of 2
Taken at least once:50.00% of 2
Calls executed:100.00% of 1
../src/example1.cpp:creating '..#src#example1.cpp.gcov'
Now I want to know what wrong I am doing? my project is complex, so I don't want to do copy all cpp files from respective 'src' folder to respective 'linux' folder. I tried with --object-directory then also same result.
gcovr uses .gcov files for analysis.
I also faced similar issue and overcame it in 2 steps by manually generating .gcov file
In the folder which contains gcno files run gcov -b -l -p -c *.gcno
This will generate gcov files with all details from gcno and gcda files.
Go to Project Root Folder and run gcovr -g -k -r . --html --html-details -o tp.html or any gcovr command with -g option, -g option tells gcovr to process gcov output files
Hope this solution Helps..
I have been working with gcovr and gcov since few months now.
The only thing that's different from what I am doing is that you are not specifying the path properly in "-r" flag.
You should specify the complete path always.
It's fine even if it's not canonical but path should be complete.
And always specify an extra slash "/" or "\" for linux and windows respectively after the root directory name.
For example
-r "/path/to/root/directory/"
It seems that this extra slash is important otherwise it gives problem.
Don't know the exact problem, but I assumed it doesn't search recursively without the end slash.
Om MacOS/Darwin with Homebrew gcc/gcovr installed, it turned out that the gcov used by gcovr was /usr/bin/gcov which is the Apple/clang version which is incompatible.
I don't understand why there is no /usr/local/bin/gcov but creating that as a link to gcov-9 solved it for me.
If applicable, turn off ccache.
If ccache ever does its thing (let's say you wiped the build directory), it will happily restore the object files from cache while not restoring the *.gcno files, because it doesn't know about those.
Related
I'm adding code coverage on a C project of mine. The process I'm following is this:
# compile a .c file, expecting two new files "a.out" and "main.gcno"
gcc --coverage main.c
# run executable to get coverage data, expecting to create a new "main.gcda" file
./a.out
# use `gcov` to get formatted reports
gcov main.c
When I'm using gcc on version 10.3.0, this all works as expected without issues. When using gcc with version 11.1.0 however, both the main.gcno and main.gcda files have a different name, which breaks the flow as explained below.
Using gcc --coverage main.c produces two files, a.out and a-main.gcno. Then running the executable with ./a.out creates a new file a-main.gcda. Notice the prefix a- on the coverage files. When running the next command gcov main.c, I get the following error:
main.gcno:cannot open notes file
main.gcda:cannot open data file, assuming not executed
Because it is looking for the files main.gcno and main.gcda, but it can't find them.
Why does the new version of gcc do that? Everything I read online assumes that the output of the compiler should be in sync with gcov when run on the same source file. I couldn't find anywhere a way to change the output name of coverage files.
In case it helps, I also noticed the a- prefix depends on the output name. So if an output name is specified (gcc --coverage main.c -o test) then the coverage files will have that as prefix (test-main.gcno and test-main.gcda).
I've also tried manually renaming the files to remove the prefix, and gcov seems happy with that. The problem is that I'm trying to automate the process, and I'd like a more robust way than trying to guess what output name the compiler uses for coverage files.
For reference, I'm also using gcov on version 11.1.0. It's not clear to me if that's related to the gcc being the same version.
Why does the new version of gcc do that?
See the release notes for GCC 11, specifically the third bullet of the Caveats which starts "Naming and location of auxiliary and dump output files changed".
Everything I read online assumes that the output of the compiler should be in sync with gcov when run on the same source file. I couldn't find anywhere a way to change the output name of coverage files.
As it says in the release notes, the -dumpbase option is what you want. To remove any prefix, use -dumpbase ''
I'm not sure whether gcov should have been updated, or if the gcc-11 change should not have affected the coverage files. Edit: This is behaving as expected.
Another solution is to compile and link in two separate steps:
gcc --coverage main.c -c
gcc --coverage main.o
This way the coverage data files do not get the prefix, and gcov finds them as expected.
I'm trying to use some ffmpeg calls in my own program, the basis of which I'm editing the ffmpeg example program remuxing.c. I'm trying to use some of the ffmpeg calls in my own program.
I'm running Ubuntu 18.04.5 on a generic Linux box.
To help better understand what I've done and where I've having problems, I'll out line what I've done and what is not working.
Steps I've successfully completed:
-- I've have downloaded the ffmpeg code base and example files
-- Next I did a './configure', then 'make', then 'make install' and 'make examples' to make the libraries and examples
-- I tested some of the examples and they ran fine from the default install directory
-- specifically, when I test remuxing.c in the original ffmpeg downloaded dir — compile and run — it works fine
./remuxing /data/iphone-h264.m4v /tmp/test15.ts
-- this creates a .ts output file that I can test and is readable by vlc
Having ensured that I correctly compiled and tested ffmpeg source and its example files, I next move to working my own program based on the example remuxing.c
— I copied the original remuxing.c into my own test directory structure
— I make it by running this to link in the required ffmpeg libraries (I think)
cc -DLINUX -o remuxing remuxing.c -I ../ffmpeg/libavformat -lavformat -I ../ffmpeg/libavcodec -lavcodec -I ../ffmpeg/libswresample -lswresample -I ../ffmpeg/libavutil -lavutil -lpthread -lm
— however when I try to generate a test16.ts file (to know it is different from the one I created before) I get an error:
./remuxing /data/iphone-h264.m4v /tmp/test16.ts
Could not open input file '/data/iphone-h264.m4v’ Error occurred: Invalid data found when processing input
This is the exact same video file the same program converted from the installed doc/examples directory.
QUESTION — why is this happening — what am I doing wrong?
I guess I may not be properly linking in the ffmpeg libraries?? -- but I'm not sure what I'm doing wrong.
I can also post my makefiles if that would help.
Would be most appreciative for any help -- thank you in advance.
What might be causing this sort of error? I am currently using lcov with Cygwin, and do not encounter any issues accessing/reading-from/writing-to the specified path when using gcc or any other Linux commands.
Just to demonstrate my exact process...
caffeine#ENG-INT /cygdrive/c/Users/caffeine/My Documents/$gcc -Wall -fprofile-arcs -ftest-coverage -o cov.exe cov.c
caffeine#ENG-INT /cygdrive/c/Users/caffeine/My Documents/$ ./cov.exe
caffeine#ENG-INT /cygdrive/c/Users/caffeine/My Documents/$ lcov --capture --directory c:/Users/caffeine/My\ Documents --output-file coverage.info
*****That last command gives this output to the console, and I cannot wrap my head around it
Capturing coverage data from c:/Users/caffeine/My Documents
Found gcov version: 5.3.0
Scanning c:/Users/caffeine/My Documents for .gcda files ...
Found 1 data files in c:/Users/caffeine/My Documents
Processing cov.gcda
geninfo:
ERROR: cannot write to directory /cygdrive/c/Users/caffeine/My Documents/c:/Users/caffeine/My Documents!
Any ideas?
Looks like the same problem as in this question.
There used to be a bug in lcov 1.12 that lead to this error messsage. Fortunately, it is fixed now. Upgrading to 1.13 should fix the problem.
My Ubuntu version is 14.04 LTS. I have a C program copied on the desktop by the name sendRawEth.c. When I write:
gcc sendRawEth.c -o sendRawEth
The compiler complains:
gcc: error: sendRawEth.c: No such file or directory
gcc: fatal error: no input files
I have no idea how to solve this error.
please do the following.
On terminal check the present directory by 'pwd' command and then check the directory in which your programme is there and see if they are same or not. And while writing gcc yourfile it's case sensitive. Hope this helps
There are 2 reasons for such errors.
You said you copied your C programs in your desktop folder.
This means you may have only copied sendRawEth.c. file format not the executable file.
You should ensure you copy the .exe files as well.
You need to change the directory to the same folder that you copied your programs into.
First, check your current folder by typing pwd.
Then change it to your required folder with:
cd /outerfolder/your program folder
Then compile it with:
gcc -o programname programname.c
And finally execute it with:
./programname
I need to perform some test coverage with gcov on a shared library I am working on.
The problem is libtool renames the object files from my-name.c to libmylib_la-my-name.lo and gcov is unable to handle that conversion. Everytime I run it, the error cannot open notes file is generated.
If I manually rename my-name.c to libmylib_la-my-name.c after the build gcov works fine, so there is no other problem apart the filename mangling.
Addendum
Trying to provide a minimal working example I discovered the filename mangling happens only when lib..._la_CFLAGS is set (and also when it is set to an empty value).
cat <<EOT > configure.ac
AC_INIT(sample,0.0.1)
AC_CONFIG_SRCDIR(configure.ac)
AM_INIT_AUTOMAKE(foreign)
LT_INIT
AC_PROG_CC
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
EOT
cat <<EOT > Makefile.am
lib_LTLIBRARIES=libsample.la
libsample_la_SOURCES=sample.c
# The following line triggers the filename mangling (libsample_la-sample.lo instead of sample.lo)
libsample_la_CFLAGS=
EOT
touch sample.c && autoreconf -if && ./configure && make
Is there a way to avoid the filename mangling operated by libtool or to let gcov understand the filename mangling scheme?
Gcov gcda and gcno files are named after object files. You can run gcov from source directory directly on object file or you can use -o option of gcov to specify the object file and corresponding gcov files.
For example I have a small project that builds a shared library. I pass gcov flags to make command:
make CFLAGS="-O0 --coverage" LDFLAGS=--coverage
Object files and corresponding gcno files are created in src/.libs folder:
$ ls -la src/.libs
libtest_la-test.o
libtest_la-test.gcno
The source file is in src folder
$ ls src/
test.c
Next I run my test suite and gcda files are created:
$ ls -la src/.libs
libtest_la-test.o
libtest_la-test.gcno
libtest_la-test.gcda
Now I can enter src directory and run gcov, specifiying object file name:
$ gcov -o .libs/libtest_la-test.o test.c
File ‘test.c’
Lines executed:27.08% of 96
Creating ‘test.c.gcov'
It is also possible to just run gcov on object file:
$ gcov .libs/libtest_la-test.o
File ’test.c’
Lines executed:27.08% of 96
Creating ’test.c.gcov'
Or even just specifying base name of object file and gcov files:
$ gcov .libs/libtest_la-test
File ’test.c’
Lines executed:27.08% of 96
Creating ’test.c.gcov'
But I would suggest another automated approach that works very well for me, using lcov. I invoke it from top directory specifying paths to source files and object files:
$ lcov --base-directory src --directory src/.libs/ --capture --output-file gcov.info
Capturing coverage data from src/.libs/
Found gcov version: 4.8.2
Scanning src/.libs/ for .gcda files ...
Found 10 data files in src/.libs/
Processing .libs/test_la-test.gcda
[…]
Finished .info-file creation
$ genhtml -o html/coverage gcov.info
Reading data file gcov.info
Found 10 entries.
Found common filename prefix "/usr/src/libtest”
Writing .css and .png files.
Generating output.
Processing file src/test.c
[…]
Writing directory view page.
Overall coverage rate:
lines......: 56.1% (2098 of 3737 lines)
functions..: 68.8% (139 of 202 functions)
Now html/coverage directory contains html files that can be easily analyzed in a web browser.
Libtool shouldn't change .c file names. However, it does change .o file names; this is because it needs to compile libraries twice on some platforms (once to create position-independent code (PIC) for .so (shared) libraries, once to create code which is not PIC for .a (static) libraries).
What you may be seeing is the fact that gcov has issues with shared libraries. See "can gcov deal with shared object?" for details.
If that doesn't fix it, I'll have to agree with Brett that you ned to supply more info.