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

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

[Mike Gilbert]

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})
 
-- 
2.11.0

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2295 bytes --]

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.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

[Mike Gilbert]

On Tue, Dec 27, 2016 at 3:22 AM, Daniel Campbell <zlg@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?

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

[Mike Gilbert]

On Tue, Dec 27, 2016 at 6:10 AM, Joakim Tjernlund
<Joakim.Tjernlund@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.

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

[A. Wilcox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/12/16 11:04, Mike Gilbert wrote:
> 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.
> 

Having tried this before, it doesn't work with Portage (at least as of
Sep 2015).  Then again, it barely works hand-hacking it manually.  :)

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYYuVnAAoJEMspy1GSK50ULqUP/jotFE2oN+fYDsp5fuFhWJg/
GFk7lj/oHa2tnQ3JqzHQ+H0/uFG98U8+fPiswCuRweJUXO1P2hbRao8EGVxYw8Xt
f+FporNTQg8jGkMRXzISKBAboqpCEOgLH3p8WYaGs6qmFIidHm3r6H7gg7y/bTf+
zKDUtlnEYAmwDV6zGF74d/lTBox3rbJqkZVAKkVZbzc8Y83tod9mNZL1goTBSfkF
z1AcSKsNtNYlQmTe7x/0LZXZ33Wi0mEqD65TaJK5aaU7l3Hu9W6DUAcZQaPlql4u
k7LkZZO2MQ+cLp68kDwxEae8ZRs/9S3bBNNH5IaI7ASdkJmPnanR22jODuQkR6C8
GNG0jJemozyTVONVAUs2FWslTxXJ/Pgdu12SnfydUci42KVvXyOtXBB7ICmo4yfN
yF4p6XXeHbmlvi8xoBLxnOxSUvrtorFzqZLK/YeiUMuSbknKDhDFL9fD+gFIBZlm
ABdiK5Z1AewrYf9WBmqj80u40bcYTU2SVN6xKgKoqYPkvfPEk+W93wmWaq0+6VX6
m+JV9UT+Jt1umY2WW0oDVlwW85QhXQPKFUTdByx2E6++iY3CiSXn6i+uDpwJt+0b
ShS6E7rQgBxfH2rwJ0sgtBgDoqYegUgrgRDgMfvO7wfjOZsF04qH/tOYz0UGuyAV
5yubToZyJRT49dRHbv91
=hkcP
-----END PGP SIGNATURE-----

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Tue, 27 Dec 2016 12:04:04 -0500
Mike Gilbert <floppym@gentoo.org> wrote:

> For a typical cross-compiler build, CHOST is unchanged from the value
> typically in make.conf, but CTARGET gets set to the "cross" arch.

Yep.

> 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.

I seem to recall installing a native compiler to /usr/${cross_arch}/
resulted in file conflicts but if that's still the case, that's a
separate issue. ROOT may possibly need to change to SYSROOT but that's
also a separate issue.

> 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.

This is called a Canadian cross. I can't remember if I ever actually
tried one but I think your change would still be correct in this case.
We don't care about CBUILD in this context.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]