[lmi] Transient ccache error

[Greg Chicares]

I created a brand-new chroot and rebuilt everything therein.
Examining the output of 'ccache -svv', I saw numerous cache
misses, although I thought I had eliminated any possibility
of that (in lmi itself, that is; autotooled libraries always
have some misses, but I've given them their own ccache
directory).

To debug this, I did 'make clean' and set "CCACHE_DEBUG=1",
then rebuilt. Again, I saw numerous cache misses. I looked
at some of the "*.ccache-log" files for x86-pc-gnu, and saw:
  Compiler not expected to produce an object file
However, googling for that yields:
  No results found for "Compiler not expected to produce an object file"
so this problem would seem to be quite rare.

Then I removed all cache files with 'ccache --clear' and
rebuilt again, and everything was fine: the build succeeded,
with zero cache misses. Similarly, I expunged the newly
created chroot and recreated it, and everything was fine.

Now I can't reproduce the problem--and the "*.ccache-log"
files with that error message were expunged when I
recreated the chroot, so I can't investigate it further.
Perhaps it'll never happen again; still, it bothers me
that I can't even imagine how it could have occurred. This
cache is shared with a predecessor chroot, deliberately,
to make creation of a brand-new chroot (using exactly the
same compiler) faster. (In this case, that condition
didn't hold, because the predecessor chroot had
  $ gcc --version
  gcc (Debian 12.2.0-3) 12.2.0
while the newer chroot has
  gcc (Debian 12.2.0-14) 12.2.0
). I may have interrupted a build with Ctrl-C, but I'd
expect ccache to recover from that when a fresh build
runs to completion. And ccache, AIUI, caches preprocessed
source files, but not compiler commands, yet the build
commands in lmi's makefiles are designed to produce object
files; the only invocations that aren't designed that way
are the ones used for the 'physical_closure' target, but
building that target never (except in this transient case,
perhaps) causes 'ccache -svv' to show any cache misses.

Since the problem seems to have resolved itself, all I
can do is record what I know about it here.