Created attachment 680908 [details] build log running `genlop -e ccache`, I can see that ccache was updated on my machine yesterday (Saturday 2 Jan 2021) from 3.7.12 to 4.1, and since then, all packages fail to build with one of the following errors: - C compiler cannot create executables - Unknown compiler(s): [['x86_64-pc-linux-gnu-gcc']] disabling the ccache feature in make conf (or via FEATURES="-ccache" on the cli) allows builds to proceed successfully. An example is from `emerge -1 --verbose faac`, with logs attached.
Created attachment 680911 [details] ccache log
I have also followed gentoo forum threads with similar errors, but none of the resolutions I've found help, including - commenting out my CFLAGS in make.conf (currently '-march=native -O2') - rebuilding & checking ldd config and I can verify that the compiler x86_64-pc-linux-gnu-gcc not only exists (and is in the path), but that it can build simple c programs (well, being able to emerge updated packages also works, so I guess that should be a given).
also, it was difficult for me to select the correct importance for this report -- technically it's a blocker because it blocks me from using ccache, but I can work around it. I've also tried a clean ccache cache dir -- no change.
Created attachment 680914 [details] ccache config file
It is sad to read that you have problems with ccache. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/
Your `build.log` says that compiler is not runnable via `ccache`: ``` checking whether the C compiler works... no configure: error: in `/var/tmp/portage/media-libs/faac-1.30/work/faac-1_30-abi_x86_32.x86': configure: error: C compiler cannot create executables See `config.log' for more details !!! Please attach the following file when seeking support: !!! /var/tmp/portage/media-libs/faac-1.30/work/faac-1_30-abi_x86_32.x86/config.log ``` Can you attach that file as well? Maybe it will tell you why things are broken.
It appears that the problem stems from the following behavior: 1. running `emerge -1 {atom}` creates the ccache log file with 644 permissions, owned by root 2. running `emerge --update --newuse --changed-use --deep --changed-deps --keep-going @world` appears to create the file, also with 644 permissions, but as the user portage So if (1) precedes (2), ccache cannot log and compilation fails. I've suggested at https://github.com/ccache/ccache/issues/767 that an inability to log should not break compilation, but it's also probably interesting that two similar emerge commands appear to be run as different users. Personally, I've worked around the issue in my update wrapper script, but I haven't needed to for the last year or so that I've been using ccache, so somewhere along the line, there's a deviance in behavior. I'm not sure if I should be logging an issue elsewhere and would appreciate input.
I'd say `log_file = /tmp/ccache.log` is an invalid user configuration. portage runs different phases by different users on purpose: - pkg_* phases are usually ran by root as they usualy apply changes to the system (and sometimes happen to run a compiler) - src_* phases are usually ran by portage user as all the changes should happen in $WORKDIR If you configure a shared place got both users to log stuff you might have to configure an empty file and it's perimissions up-front (I'm assuming ccache would only append to the file, thus /etc/local.d/ might be good enough for it).
