Since a large update with glib portage and other gcc related packages all ebuilds fail either before the config phase, because they try to access /usr/local/include, which links currently to /usr/include/ (Sandbox violation?) or in the config phase, where gcc tries to access /usr/local/include. The test fails, so gcc can't generate executables (see also glib-config.log in attachments). In /usr/local/portage is a local overlay. Maybe this is related, but I deactivated it already. Possibly the glib update fixes this, but I can't update anymore. Reproducible: Always Steps to Reproduce: 1. emerge any package (e.g. bzip2) 2. 3. Actual Results: All ebuild fail before or in config phase. Expected Results: The ebuilds should just compile. I'll attach emerge --info, config.log of glib, build.log of bzip2. Other ebuilds, which failed, were: mail-client/mutt-1.5.22-r3, media-sound/audacity-2.0.2, sys-libs/libselinux-2.2.1-r1.
Created attachment 372810 [details] Output of emerge --info
Created attachment 372812 [details] build.log of failed compilation of bzip2-1.0.6-r6
Created attachment 372814 [details] configure phase of dev-libs/glib-2.38.2-r1 If this is already fixed, I would appreciate a step by step guide to fix my broken portage/gcc.
cc1: error: /usr/local/include: Permission denied What would explain that? It's not a sandbox violation - apparently the directory permissions are bad, which in case of a symlink points to those of /usr/include. Normally /usr/local/include does not exist on Gentoo installs, so if you have it you probably worked around the package manager at some point. Please post your `ls -ld /usr/{,local/}include' output.
Created attachment 372854 [details] emerge.log since the last big working update I noticed, that portage was working directly after the update. Maybe a reboot was required to get to this point. About your comment: The symlink was created by me, after I saw, that gcc tried to access it. Sorry for not pointing that out. If I remove it, the bug stays the same.
As I said, I created the symlink as a try to workaround the problem. Nevertheless here is the output: drwxr-xr-x. 280 root root 40960 Mar 16 21:47 /usr/include lrwxrwxrwx. 1 root root 13 Mar 17 11:54 /usr/local/include -> /usr/include/ Please note that I removed and recreated the symlink in the meantime. I'll remove it now.
What information did you actually need? I resolved the bug by restoring the base system from a hardened stage archive, so I don't care about the status. Gcc is running again. To be on the safe side, I'm running emerge -eq system and world.
