Closed Romain-Geissler-1A closed 3 years ago
Unrelated, but I thought I should mention it anyway:
We do run ccache with this in the environment:
CCACHE_NOLINK='1'
CCACHE_NOLINK
was removed in ccache 2.2 (18 years ago) and thus has no effect.
Hi,
Thanks for the information for CCACHE_NOLINK, I will remove that from our build system.
Do you know roughly already when you will release officially 4.0.1 (just for me to know if I shall cherry-pick this commit locally and apply it to 4.0 or wait for a more official release).
Cheers, Romain
Do you know roughly already when you will release officially 4.0.1
No, but it shouldn't be many weeks away. As always, it depends on when I have enough spare time and interest.
(this is a copy paste of what I wrote already in issue #703).
Hi,
FYI I recently tried to migrate my company builds to ccache 4.0 (we used 3.7.12 before) and indeed several different unrelated teams started to report me such errors.
I am right now not 100% sure this actually comes from ccache 4.0, but time wise, the problem started to happen when I switched it on by default. Our setup is:
Linux OSes shared NFS ccache directories. So in our cases, chmod/umask is important. It apparently happens on one of my ccache folder too, where only 2 users that I trust are using. I can see the following folder/rights:
as you can see, some folders are created with chmod 777 (so that anyone can update it, as expected for NFS ccache folder) while others are not writable by group/other. It seems strange, because normally that "combld" user shall always use the same config with the same umask when launching ccache. I don't have more details yet.