Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls

[Joakim Tjernlund]

On Tue, 2016-12-27 at 00:22 -0800, Daniel Campbell 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.

Will that work for cross toolchains well?

   Jocke