Current man make.conf says this: ccache Enable portage support for the ccache package. If the ccache dir is not present in the user's environment, then portage will default to ${PORTAGE_TMPDIR}/ccache. Warning: This feature is known to cause numerous compilation failures. Sometimes ccache will retain stale code objects or corrupted files, which can lead to packages that cannot be emerged. If this happens (if you receive errors like "File not recognized: File truncated"), try recompiling the application with ccache disabled before reporting a bug. Unless you are doing development work, do not enable ccache. But I think that, even if some times a bug like that "File truncated" can appear, they are far less common with recent ccache versions (like current stable 3.1.9). Also, taking care that people now needs to rebuild things much more often with subslots, ccache can gain a lot of time with a USE or subslot is switched (for example on icu bumps, or webkit-gtk...) I would put a much more soft warning simply telling users that errors like "File truncated" can be caused by ccache but, apart of that, I don't think we need to tell people that they shouldn't use it if they don't do development work. (well, would be nice if portage could suggest that if that error is found in build.log and FEATURES ccache is enabled, but I don't know if that would be possible) Thanks
I still receive bogus bug reports because of ccache on a semi-regular basis. (In reply to Pacho Ramos from comment #0) > Also, taking care that people now needs to rebuild things > much more often with subslots, ccache can gain a lot of time with a USE or > subslot is switched (for example on icu bumps, or webkit-gtk...) Why does subslots mean more rebuilds? If there was breakage, the user had to rebuild anyway before subslots.
(In reply to Pacho Ramos from comment #0) > But I think that, even if some times a bug like that "File truncated" can > appear, they are far less common with recent ccache versions (like current > stable 3.1.9). I'd say "far less common" is not good enough. Is the cause for these problems still unknown? If you want to improve the situation, get people to fix the bug properly.
(In reply to Sebastian Luther (few) from comment #2) > (In reply to Pacho Ramos from comment #0) > > But I think that, even if some times a bug like that "File truncated" can > > appear, they are far less common with recent ccache versions (like current > > stable 3.1.9). > > I'd say "far less common" is not good enough. Is the cause for these > problems still unknown? If you want to improve the situation, get people to > fix the bug properly. I am also happy with the warnings for now. The whole point of the cache is to be coherent, if it isn't then I don't think we should advocate its use in our own documentation. Users are fully able to go against our advise. -A
But, are that problems being reported to upstream even? I haven't suffered one of them for a long time and, then, I cannot report to upstream a bug that I haven't suffered with any 3.x version for example
(In reply to Pacho Ramos from comment #4) > But, are that problems being reported to upstream even? I don't know. Maybe the bug wranglers know recent cases.
Seems the consensus was WONTFIX. Pablo, feel free to reopen and argue your present case if you feel that it's wrong.
