gcc-config fails to fall back to manual CHOST detection if Python is installed and working but portageq is broken. Reproducible: Always Steps to Reproduce: $ sudo chmod 0 /etc/portage/package.keywords # to break portageq for non-root $ gcc-config -l Actual Results: * gcc-config: Could not get portage CHOST! * gcc-config: You should verify that CHOST is set in one of these places: * gcc-config: - //etc/portage/make.conf * gcc-config: - active environment Expected Results: gcc-config lists the installed configurations. If anything under /etc/portage is unreadable by the effective user, portageq will die with a PermissionDenied exception. This should probably be treated the same way as Python breakage and fall back to the manual search (as the error message suggests it will do). Patch to come.
Created attachment 312863 [details, diff] Patch to gcc-config to fix fallback
i don't know about this. do you have any legitimate cases where this happens ?
I came across this problem because mingw32-gcc failed, but it looks like that was caused by not updating the current compiler after emerge --depclean. So no, I don't currently have a case where this breaks anything.
i filed bug 418475 for making portageq/etc... more resilient. no reason those files being inaccessible as non-root would keep them from providing useful info.
