Unlike other tools such as gdb that need source files, gcov does not store the absolute path. As a result, gcov must be run in the same directory in which gcc was invoked. This makes it particularly difficult to generate coverage reports for separately compiled libraries that have separate src/ and build/ directories.

Below is a shell script that demonstrates the problem.

#!/bin/sh

rm -rf src build bin coverage
mkdir src build bin coverage
echo 'int main() {return 0;}' > src/test.c
gcc -c -o build/test.o -g -fprofile-arcs -ftest-coverage src/test.c
gcc -o bin/test -g -fprofile-arcs -ftest-coverage build/test.o
./bin/test
cd coverage
gcov -o ../build ../src/test.c

As an addendum to this bug, if the absolute path to the object file was also saved in the .gcda or .gcno file with the absolute path to the source file, then one could generate coverage files using simply:

gcov ../build/test.gcna

(Currently one can specify the .gcna file this way, but one must run gcov in the original build directory due to the relative source file path bug, and also specify "-o build" since the object file path is not saved in the .gcna/.gcno file.)