Thanks, it's perfectly clear now.

Sooo is there any way we could get a gcda sloppiness for people who don't plan to move their binaries around (at least not before generating the coverage reports)?

Moving the binary was maybe not the ideal example. 🙂 The problem is that is if you compile an object file in a directory and then use it in a build in another directory (which is what would happen if ccache allowed it) then the resulting program will write the .gcda file to the wrong directory.

That is, if ccache would allow "gcda sloppiness" something like this would happen:

$ echo 'int main(){}' >example.c
$ cd dir1
$ ccache gcc -fprofile-arcs -c ../example.c
$ strings example.o | grep dir
/path/to/dir1/example.gcda
$ cd ../dir2
$ ccache gcc -fprofile-arcs -c ../example.c
$ strings example.o | grep dir
/path/to/dir1/example.gcda
$ gcc example.o -lgcov -o example
$ ./example
$ ls example.gcda
ls: cannot access 'example.gcda': No such file or directory
$ ls ../dir1/example.gcda
../dir1/example.gcda

It would be easy to add a gcda sloppiness, but I don't see how that would be useful to anyone when the program will be broken? (If you don't care about profiling information, compile without -fprofile-arcs?)

Actually, the above already happens for relative paths, which is a bug... Fixed in 350d354.

Thanks again for the helpful example! I understand the problem better now. However, it looks to me like the problem occurs because example.o still contains the absolute path (/path/to/dir1/example.gcda). If it contained the relative path (./example.gcda) then the gcda file would always be written next to the correct example.o file (dir1/example.o in the first case, dir2/example.o in the second case), am I wrong? At least that's how I would want the gcda-sloppiness to work.

If it contained the relative path (./example.gcda) then the gcda file would always be written next to the correct example.o file

That's true. However, I'm not aware of any way to tell the compiler to insert a relative path.

I played around with some of the gcc options but I couldn't find a way to achieve this either. Instead of digging further to come up with some (most likely pretty awful) hack it is easier to work from the other end and ensure that compilation happens in the same location always. This can be achieved by mounting the source code into a container at a pre-defined location. Thanks for your great patience as always @jrosdahl. You may close the discussion if you like.