On Tue, Dec 27, 2016 at 6:10 AM, Joakim Tjernlund
<joakim.tjernl...@infinera.com> wrote:
> 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?
I was hoping someone would be paying enough attention to ask this question. ;-)
I *think* it will still work for cross-toolchains. If someone can
think of a way this will break, please share.
For a typical cross-compiler build, CHOST is unchanged from the value
typically in make.conf, but CTARGET gets set to the "cross" arch.
In the case where we are cross-compiling a native compiler, CHOST
would be taken from ${ROOT}/etc/portage/make.conf, and ROOT would
typically be something like /usr/${cross_arch}/. So I think we are
safe there as well.
What I'm very unsure of is cross-compiling a cross-compiler CBUILD !=
CHOST != CTARGET. That requires a bit of thought. I'm not sure we even
really support that in toolchain.eclass though.
