Working ccache configuration for buildworld on amd64?

Maxim Khitrov mkhitrov at gmail.com
Fri Aug 15 15:22:03 UTC 2008


On Fri, Aug 15, 2008 at 10:48 AM, RW <fbsd06 at mlists.homeunix.com> wrote:
> On Thu, 14 Aug 2008 16:04:52 -0400
> "Maxim Khitrov" <mkhitrov at gmail.com> wrote:
>
>> This is an old problem, but so far I haven't been able to find a
>> solution. When ccache is used to build world on amd64, the process
>> fails when /usr/src/lib/csu/i386-elf/crt1.c is compiled. If
>> WITHOUT_LIB32 is added to src.conf, this problem does not happen.
>> Likewise, building without ccache works fine.
>
> I take it that you've already tried removing any unnecessary settings
> such as CFLAGS.
>
> What interesting about this is that it's failing on a compile; i.e. on a
> cache miss, when ccache is doing next to nothing. That suggests that
> there's either a problem in the way that the real compiler is invoked
> by ccache, or that the real failure occurred during the building
> of the toolchain and it's dependencies.
>
> I'd try setting CCACHE_RECACHE temporarily in the environment, to flush
> out the old cached files, and see if it makes a difference.

I only set the CPUTYPE in make.conf, CFLAGS are untouched. Clearing
out the repository (ccache -C) doesn't help.

I think what's happening is that there is a collision in hash values
generated by ccache. That's the only thing I can think of, because
crt1.c is compiled twice; once from /usr/src/lib/csu/amd64/crt1.c, and
a second time from /usr/src/lib/csu/i386-elf/crt1.c. If LIB32 is
disabled in src.conf, only the first compilation takes place. If the
generated hash values are the same, by some chance, then the actual
problem is that the file is not compiled a second time when, in fact,
it should be. This is only a guess, however.

- Max


More information about the freebsd-questions mailing list