On Tue, Dec 27, 2016 at 3:22 AM, Daniel Campbell <z...@gentoo.org> wrote: > On 12/26/2016 12:22 PM, Mike Gilbert wrote: >> Bug: https://bugs.gentoo.org/603776 >> --- >> eclass/toolchain.eclass | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass >> index 55249b00249b..97511ee12440 100644 >> --- a/eclass/toolchain.eclass >> +++ b/eclass/toolchain.eclass >> @@ -2119,13 +2119,13 @@ >> >> do_gcc_config() { >> if ! should_we_gcc_config ; then >> - env -i ROOT="${ROOT}" gcc-config --use-old --force >> + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old >> --force >> return 0 >> fi >> >> local current_gcc_config target >> >> - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} >> 2>/dev/null) >> + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config >> -c ${CTARGET} 2>/dev/null) >> if [[ -n ${current_gcc_config} ]] ; then >> local current_specs use_specs >> # figure out which specs-specific config is active >> @@ -2159,12 +2159,12 @@ should_we_gcc_config() { >> # if the current config is invalid, we definitely want a new one >> # Note: due to bash quirkiness, the following must not be 1 line >> local curr_config >> - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) || >> return 0 >> + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c >> ${CTARGET} 2>&1) || return 0 >> >> # if the previously selected config has the same major.minor (branch) >> as >> # the version we are installing, then it will probably be uninstalled >> # for being in the same SLOT, make sure we run gcc-config. >> - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S >> ${curr_config} | awk '{print $2}') >> + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" >> gcc-config -S ${curr_config} | awk '{print $2}') >> >> local curr_branch_ver=$(get_version_component_range 1-2 >> ${curr_config_ver}) >> >> > > Seems like an obvious bug and fix; is there any reason passing CHOST > around might be a bad idea? It seems to me that it enforces the behavior > it's meant to have to begin with and makes it more obvious that CHOST is > used.
I am honestly not sure why the eclass is calling env -i in the first place. It looks like vapier added that; maybe he can explain it?
