Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On Tue, 27 Dec 2016 12:04:04 -0500
Mike Gilbert 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
pgpd5udVmCqmF.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
-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
On Tue, Dec 27, 2016 at 6:10 AM, Joakim Tjernlund
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
On Tue, Dec 27, 2016 at 3:22 AM, 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.
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
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
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
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
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
