Created attachment 402136 [details, diff] toolchain.eclass patch Spotted a pretty suspicious behavior: > * Messages for package sys-devel/gcc-4.8.3: > > * The currently selected specs-specific gcc config, > * > * > * > * py2.7.egg-info > * > * py2.7.egg-info (this goes on for ages) > * py2.7.egg-info > * > * > * > * > * py2.7.egg-info, doesn't exist anymore. This is usually > * due to enabling/disabling hardened or switching to a version > * of gcc that doesnt create multiple specs files. The default > * config will be used, and the previous preference forgotten. > * gcc-config: Active gcc profile is invalid! In the end the correct thing happens and gcc-config sets a valid profile but that output sure is scary. The issue is a mix of gcc-config reporting error messages to stdout and toolchain.eclass not quoting the output of gcc-config or checking its exit code. The problematic code: > local current_gcc_config="" current_specs="" use_specs="" > > current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>/dev>/null) > if [[ -n ${current_gcc_config} ]] ; then > # figure out which specs-specific config is active > current_specs=$(gcc-config -S ${current_gcc_config} | awk '{print $3}') > [[ -n ${current_specs} ]] && use_specs=-${current_specs} > fi When `gcc-config -c` fails $current_gcc_config becomes something like: > * gcc-config: No gcc profile is active! That in turn gets passed unquoted to gcc-config again, allowing * to expand to any number of things. The attached patch fixes this logic to explicitly check the exit code of gcc-config. For extra safety some quotes are added too. Overall this eclass is way to lax on its use of quotes. :(
After pondering this a bit longer I suspected that yet another oddity is playing a role here. The behavior reported here is on a system without openrc installed and thus /etc/init.d/functions.sh is provided by a substitute implementation and gcc-config-1.7.3 predates the switch to /lib/gentoo/functions.sh. On a system with openrc errors reported by gcc-config do get properly sent to stderr instead of stdout. So on my end I should be able to fix this particular issue by adjusting the behavior of functions.sh but being a bit more careful and quoting gcc-config's output and checking exit code wouldn't hurt. :) For reference the functions.sh implementation at issue here is https://github.com/marcusatbang/efunctions and it appears that the original baselayout-1 implementations also used stdout, not stderr. https://sources.gentoo.org/cgi-bin/viewvc.cgi/baselayout/branches/baselayout-1_13/sbin/functions.sh?revision=2546&view=markup#l291 Filed a bug with efuctions: https://github.com/marcusatbang/efunctions/issues/9
Looks like gentoo-functions returns to the older baselayout-1 behavior of logging all levels to stdout so this *will* be a problem for newer versions of gcc-config https://github.com/gentoo/gentoo-functions/blob/master/functions.sh#L190
Added a FYI note to the bug for converting gcc-config to gentoo-functions since this bug will impact the newer gcc-config. https://bugs.gentoo.org/show_bug.cgi?id=504118#c12
That explains a bizarre error I got a couple days ago. Masked for now. +# Ryan Hill <rhill@gentoo.org> (28 Apr 2015) +# Moving to /lib/gentoo/functions.sh broke the eclass +# by changing output it relies on. See bug #504118, +# 547586, and 547962. +>=sys-devel/gcc-config-1.8-r1
Now that gentoo-functions has been fixed do we still need to do anything here?
(In reply to Ryan Hill from comment #5) no, toolchain.eclass is working correctly
