unexpected results when using -MD or -MMD compiler options

[jmacfarlane]

The resulting dependency file is not always correct when specifying the -MD or -MMD options to the compiler.

example:

$ # Make two identical source directories
$ mkdir a
$ touch a/source.c
$ rsync -a a/ b
$
$ # Cache entry added for directory "a"
$ ccache /usr/bin/cc -MMD -c a/source.c && cat source.d
source.o: a/source.c
$
$ # Cache entry added for directory "b"
$ ccache /usr/bin/cc -MMD -c b/source.c && cat source.d
source.o: b/source.c
$
$ # Incorrect cached results used for directory "a"
$ ccache /usr/bin/cc -MMD -c a/source.c && cat source.d
source.o: b/source.c
$
$ # Verify compiler gives different results
$ /usr/bin/cc -MMD -c a/source.c && cat source.d
source.o: a/source.c

The Ninja generator of CMake uses the -MMD compiler option to cache dependencies. This means that anyone using Ninja with a CMake project will encounter this bug if the source code is moved.

[tanstafel]

Is it possible that this issue also causes issue #133? I ask because I see the -MD switch used in the .cmd files the kernel build process creates.

[jrosdahl]

The resulting dependency file is not always correct when specifying the -MD or -MMD options to the compiler.

Thanks for the bug report and excellent reproduction example!

This is regression introduced as a side effect of #88. First affected ccache version: 3.3.

[jrosdahl]

Is it possible that this issue also causes issue #133? I ask because I see the -MD switch used in the .cmd files the kernel build process creates.

I haven't had time to look at #133 in detail yet (I have a two weeks old daughter that competes with my spare time), but my current guess is that #133 and #134 are unrelated. I think that your "there is another more hidden issue" problem in #133 might be caused by #134, though.

[jrosdahl]

Fixed in ccache 3.3.2.

[jrmrjnck]

This still doesn't work for situations where the source file stays in the same place, but the include paths change. Consider the following:

$ mkdir inc_a inc_b
$ touch inc_a/source.h inc_b/source.h
$ echo '#include <source.h>' > source.c
$ ccache gcc -MMD -Iinc_a -c source.c && cat source.d
source.o: source.c inc_a/source.h
$ ccache gcc -MMD -Iinc_b -c source.c && cat source.d
source.o: source.c inc_b/source.h
$ ccache gcc -MMD -Iinc_a -c source.c && cat source.d
source.o: source.c inc_b/source.h

[jrmrjnck]

This is still broken in 3.3.3. Can this bug be reopened?

[jrosdahl]

Thanks! I hope to find time to have a look at this this weekend.

[amerlyq]

I remember in mailing list of ccache were mentioned problems with kernel having zero hits on second fresh compilation: https://www.mail-archive.com/ccache@lists.samba.org/msg01055.html
Is this issue related to that problem and therefore fixes both of them? Or the problem with kernel persists?

[jrosdahl]

I remember in mailing list of ccache were mentioned problems with kernel having zero hits on second fresh compilation: https://www.mail-archive.com/ccache@lists.samba.org/msg01055.html
Is this issue related to that problem and therefore fixes both of them?

Don't think so, since this issue was a regression in ccache 3.3, which was released 2016, while the mail thread you refer to is from 2014.

Or the problem with kernel persists?

Don't know.