Patchwork [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

login
register
mail settings
Submitter Matthew McClintock
Date Nov. 23, 2011, 9:40 a.m.
Message ID <1322041226-10075-1-git-send-email-msm@freescale.com>
Download mbox | patch
Permalink /patch/15325/
State New
Headers show

Comments

Matthew McClintock - Nov. 23, 2011, 9:40 a.m.
Without some sort of dependency on the HOST arch this "fake"
target package will be reused on a 32bit system even if it was
built on a 64bit system.

This new dependecy should prevent that from occuring.

Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Comments? I still this this is VERY BAD since it will trigger
all TARGET cache to be rebuilt just because we changed ARCH.
However, it should generate working sstate-cache. Might
address this issue:

| checking for /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -m32 -mhard-float  -mcpu=e500mc -isystem/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds/usr/include -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/bin/ -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/lib/ -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/include -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/sys-include --sysroot=/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap   option to accept ISO C89... none needed
| checking how to run the C preprocessor... /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E
| configure: error: in `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/powerpc-fsl-linux/libgcc':
| configure: error: C preprocessor "/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E" fails sanity check
| See `config.log' for more details.
| make[1]: *** [configure-target-libgcc] Error 1
| make[1]: Leaving directory `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux'
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| ERROR: Function 'do_compile' failed (see /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/temp/log.do_compile.27393 for further information)

 meta/recipes-devtools/gcc/gcc-4.6.inc   |    2 +-
 meta/recipes-devtools/gcc/gcc-cross.inc |   11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletions(-)
Khem Raj - Nov. 24, 2011, 3:28 a.m.
On Wed, Nov 23, 2011 at 1:40 AM, Matthew McClintock <msm@freescale.com> wrote:
> Without some sort of dependency on the HOST arch this "fake"
> target package will be reused on a 32bit system even if it was
> built on a 64bit system.
>
> This new dependecy should prevent that from occuring.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> Comments? I still this this is VERY BAD since it will trigger
> all TARGET cache to be rebuilt just because we changed ARCH.
> However, it should generate working sstate-cache. Might
> address this issue:
>
> | checking for /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -m32 -mhard-float  -mcpu=e500mc -isystem/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds/usr/include -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/bin/ -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/lib/ -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/include -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/sys-include --sysroot=/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap   option to accept ISO C89... none needed
> | checking how to run the C preprocessor... /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E
> | configure: error: in `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/powerpc-fsl-linux/libgcc':
> | configure: error: C preprocessor "/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E" fails sanity check
> | See `config.log' for more details.
> | make[1]: *** [configure-target-libgcc] Error 1
> | make[1]: Leaving directory `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux'
> | make: *** [all] Error 2
> | ERROR: oe_runmake failed
> | ERROR: Function 'do_compile' failed (see /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/temp/log.do_compile.27393 for further information)
>
>  meta/recipes-devtools/gcc/gcc-4.6.inc   |    2 +-
>  meta/recipes-devtools/gcc/gcc-cross.inc |   11 +++++++++++
>  2 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
> index f7bcf30..ee42fa7 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
> @@ -1,6 +1,6 @@
>  require gcc-common.inc
>
> -PR = "r10"
> +PR = "r11"
>
>  # Third digit in PV should be incremented after a minor release
>  # happens from this branch on gcc e.g. currently its 4.6.0
> diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
> index 5a796bc..9f6d6ad 100644
> --- a/meta/recipes-devtools/gcc/gcc-cross.inc
> +++ b/meta/recipes-devtools/gcc/gcc-cross.inc
> @@ -10,3 +10,14 @@ do_compile () {
>        oe_runmake all-host all-target-libgcc
>  }
>
> +# gcc-cross is special since it builds a HOST binary on
> +# as a TARGET recipe. This is a hack to pull in the
> +# BUILD_ARCH to the recipe so the sstate-cache is
> +# different if the HOST ARCH has changed. By expanding
> +# right now we assure it's going to be in the sig
> +BUILD_ARCH_EXPANDED := "${BUILD_ARCH}"
> +
> +# we also add this to the PV so its clear in filenames
> +# that this is arch specific even though it's labeled as
> +# a target package
> +PV .= "+${BUILD_ARCH_EXPANDED}"
> --
> 1.7.6.1
>

isnt BUILD_ARCH in signature
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
McClintock Matthew-B29882 - Nov. 24, 2011, 3:35 a.m.
On Wed, Nov 23, 2011 at 9:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Nov 23, 2011 at 1:40 AM, Matthew McClintock <msm@freescale.com> wrote:
>> Without some sort of dependency on the HOST arch this "fake"
>> target package will be reused on a 32bit system even if it was
>> built on a 64bit system.
>>
>> This new dependecy should prevent that from occuring.
>>
>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>> ---
>> Comments? I still this this is VERY BAD since it will trigger
>> all TARGET cache to be rebuilt just because we changed ARCH.
>> However, it should generate working sstate-cache. Might
>> address this issue:
>>
>> | checking for /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -m32 -mhard-float  -mcpu=e500mc -isystem/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds/usr/include -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/bin/ -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/lib/ -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/include -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/sys-include --sysroot=/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap   option to accept ISO C89... none needed
>> | checking how to run the C preprocessor... /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E
>> | configure: error: in `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/powerpc-fsl-linux/libgcc':
>> | configure: error: C preprocessor "/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E" fails sanity check
>> | See `config.log' for more details.
>> | make[1]: *** [configure-target-libgcc] Error 1
>> | make[1]: Leaving directory `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux'
>> | make: *** [all] Error 2
>> | ERROR: oe_runmake failed
>> | ERROR: Function 'do_compile' failed (see /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/temp/log.do_compile.27393 for further information)
>>
>>  meta/recipes-devtools/gcc/gcc-4.6.inc   |    2 +-
>>  meta/recipes-devtools/gcc/gcc-cross.inc |   11 +++++++++++
>>  2 files changed, 12 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
>> index f7bcf30..ee42fa7 100644
>> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
>> @@ -1,6 +1,6 @@
>>  require gcc-common.inc
>>
>> -PR = "r10"
>> +PR = "r11"
>>
>>  # Third digit in PV should be incremented after a minor release
>>  # happens from this branch on gcc e.g. currently its 4.6.0
>> diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
>> index 5a796bc..9f6d6ad 100644
>> --- a/meta/recipes-devtools/gcc/gcc-cross.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-cross.inc
>> @@ -10,3 +10,14 @@ do_compile () {
>>        oe_runmake all-host all-target-libgcc
>>  }
>>
>> +# gcc-cross is special since it builds a HOST binary on
>> +# as a TARGET recipe. This is a hack to pull in the
>> +# BUILD_ARCH to the recipe so the sstate-cache is
>> +# different if the HOST ARCH has changed. By expanding
>> +# right now we assure it's going to be in the sig
>> +BUILD_ARCH_EXPANDED := "${BUILD_ARCH}"
>> +
>> +# we also add this to the PV so its clear in filenames
>> +# that this is arch specific even though it's labeled as
>> +# a target package
>> +PV .= "+${BUILD_ARCH_EXPANDED}"
>> --
>> 1.7.6.1
>>
>
> isnt BUILD_ARCH in signature

This is a TARGET recipe, so it should *not* be right? By doing what is
above I've added it. Although I habe not  extensively tested this
modification...

-M
Khem Raj - Nov. 24, 2011, 3:37 a.m.
On Wed, Nov 23, 2011 at 7:35 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Wed, Nov 23, 2011 at 9:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Wed, Nov 23, 2011 at 1:40 AM, Matthew McClintock <msm@freescale.com> wrote:
>>> Without some sort of dependency on the HOST arch this "fake"
>>> target package will be reused on a 32bit system even if it was
>>> built on a 64bit system.
>>>
>>> This new dependecy should prevent that from occuring.
>>>
>>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>>> ---
>>> Comments? I still this this is VERY BAD since it will trigger
>>> all TARGET cache to be rebuilt just because we changed ARCH.
>>> However, it should generate working sstate-cache. Might
>>> address this issue:
>>>
>>> | checking for /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -m32 -mhard-float  -mcpu=e500mc -isystem/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds/usr/include -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/bin/ -B/home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/lib/ -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/include -isystem /home/liut/poky/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/sys-include --sysroot=/home/liut/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap   option to accept ISO C89... none needed
>>> | checking how to run the C preprocessor... /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E
>>> | configure: error: in `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/powerpc-fsl-linux/libgcc':
>>> | configure: error: C preprocessor "/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/xgcc -B/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux/./gcc/ -E" fails sanity check
>>> | See `config.log' for more details.
>>> | make[1]: *** [configure-target-libgcc] Error 1
>>> | make[1]: Leaving directory `/home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/gcc-4_6-branch/build.i686-linux.powerpc-fsl-linux'
>>> | make: *** [all] Error 2
>>> | ERROR: oe_runmake failed
>>> | ERROR: Function 'do_compile' failed (see /home/liut/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/gcc-cross-intermediate-4.6.1+svnr175454-r10/temp/log.do_compile.27393 for further information)
>>>
>>>  meta/recipes-devtools/gcc/gcc-4.6.inc   |    2 +-
>>>  meta/recipes-devtools/gcc/gcc-cross.inc |   11 +++++++++++
>>>  2 files changed, 12 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> index f7bcf30..ee42fa7 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> @@ -1,6 +1,6 @@
>>>  require gcc-common.inc
>>>
>>> -PR = "r10"
>>> +PR = "r11"
>>>
>>>  # Third digit in PV should be incremented after a minor release
>>>  # happens from this branch on gcc e.g. currently its 4.6.0
>>> diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
>>> index 5a796bc..9f6d6ad 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-cross.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-cross.inc
>>> @@ -10,3 +10,14 @@ do_compile () {
>>>        oe_runmake all-host all-target-libgcc
>>>  }
>>>
>>> +# gcc-cross is special since it builds a HOST binary on
>>> +# as a TARGET recipe. This is a hack to pull in the
>>> +# BUILD_ARCH to the recipe so the sstate-cache is
>>> +# different if the HOST ARCH has changed. By expanding
>>> +# right now we assure it's going to be in the sig
>>> +BUILD_ARCH_EXPANDED := "${BUILD_ARCH}"
>>> +
>>> +# we also add this to the PV so its clear in filenames
>>> +# that this is arch specific even though it's labeled as
>>> +# a target package
>>> +PV .= "+${BUILD_ARCH_EXPANDED}"
>>> --
>>> 1.7.6.1
>>>
>>
>> isnt BUILD_ARCH in signature
>
> This is a TARGET recipe, so it should *not* be right?

no this is a cross recipe.

By doing what is
> above I've added it. Although I habe not  extensively tested this
> modification...
>
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
McClintock Matthew-B29882 - Nov. 24, 2011, 3:55 a.m.
On Wed, Nov 23, 2011 at 9:37 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> isnt BUILD_ARCH in signature
>>
>> This is a TARGET recipe, so it should *not* be right?
>
> no this is a cross recipe.

This is built in tmp/work/ppce5500-fsl-linux/gcc-cross-*

That's a TARGET package, even though it run on on the HOST... changing
from x86 to X86-64 causes problems - hence the whole problem?

-M
McClintock Matthew-B29882 - Nov. 24, 2011, 3:55 a.m.
On Wed, Nov 23, 2011 at 9:54 PM, Matthew McClintock <msm@freescale.com> wrote:
> On Wed, Nov 23, 2011 at 9:37 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> isnt BUILD_ARCH in signature
>>>
>>> This is a TARGET recipe, so it should *not* be right?
>>
>> no this is a cross recipe.
>
> This is built in tmp/work/ppce5500-fsl-linux/gcc-cross-*
>
> That's a TARGET package, even though it run on on the HOST... changing
> from x86 to X86-64 causes problems - hence the whole problem?

Actually the reverse causes the problem: x86-64 to x86... because the
packages won't be recompiled and the 64bit stuff won't run on 32bit
host?

-M
Khem Raj - Nov. 24, 2011, 7:21 a.m.
On Wed, Nov 23, 2011 at 7:55 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Wed, Nov 23, 2011 at 9:54 PM, Matthew McClintock <msm@freescale.com> wrote:
>> On Wed, Nov 23, 2011 at 9:37 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> isnt BUILD_ARCH in signature
>>>>
>>>> This is a TARGET recipe, so it should *not* be right?
>>>
>>> no this is a cross recipe.
>>
>> This is built in tmp/work/ppce5500-fsl-linux/gcc-cross-*
>>
>> That's a TARGET package, even though it run on on the HOST... changing
>> from x86 to X86-64 causes problems - hence the whole problem?
>
> Actually the reverse causes the problem: x86-64 to x86... because the
> packages won't be recompiled and the 64bit stuff won't run on 32bit
> host?
>

hmmm I guess cross recipes are special they should not have been built
under target recipes. Adding build arch to package name would be ok
too but may be if they were built under directory of their own which
was something like <build>-<host>-<target> then it would also solve
the problem i think
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
McClintock Matthew-B29882 - Nov. 24, 2011, 7:29 a.m.
On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj <raj.khem@gmail.com> wrote:
> hmmm I guess cross recipes are special they should not have been built
> under target recipes. Adding build arch to package name would be ok
> too but may be if they were built under directory of their own which
> was something like <build>-<host>-<target> then it would also solve
> the problem i think

I agree - this is the discussion I'm trying to start. ;)

-M
Richard Purdie - Nov. 24, 2011, 10:40 a.m.
On Thu, 2011-11-24 at 07:29 +0000, McClintock Matthew-B29882 wrote:
> On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > hmmm I guess cross recipes are special they should not have been built
> > under target recipes. Adding build arch to package name would be ok
> > too but may be if they were built under directory of their own which
> > was something like <build>-<host>-<target> then it would also solve
> > the problem i think
> 
> I agree - this is the discussion I'm trying to start. ;)

I haven't had a chance to look into this in detail but the cross recipes
have been bothering me for a *long* time. I keep taking chunks of time
and dealing with issues. For example, packaging no longer happens in any
of the cross recipes, thankfully. We can share the gcc sources directory
and so on.

Those changes all open up the possibility of moving them to the native
build directory. The only missing piece left is suffixing the recipe
names with the TARGET_ARCH (like gcc-cross-canadian does, its been proof
of concept'd there).

Cheers,

Richard
Phil Blundell - Nov. 24, 2011, 10:54 a.m.
On Thu, 2011-11-24 at 07:29 +0000, McClintock Matthew-B29882 wrote:
> On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > hmmm I guess cross recipes are special they should not have been built
> > under target recipes. Adding build arch to package name would be ok
> > too but may be if they were built under directory of their own which
> > was something like <build>-<host>-<target> then it would also solve
> > the problem i think
> 
> I agree - this is the discussion I'm trying to start. ;)

It's certainly true that the way the cross recipes are done at the
moment does suck.  Really, they should be built as primarily native and
the target arch ought to just be encoded into ${PN} somehow, rather than
the current arrangement of pretending that they are target recipes.
(All the runtime bits are, or should be, packaged separately by either
libgcc or gcc-runtime so they will already get the right PACKAGE_ARCH.)

There are some old (and probably rather bit-rotten) patches to do that
in the pb/toolchain-desuck branch of oe-classic.  I'm not sure whether
any of that stuff will apply to modern oe-core but the general principle
ought still to be valid.

p.
Khem Raj - Nov. 24, 2011, 6:03 p.m.
On (24/11/11 10:54), Phil Blundell wrote:
> On Thu, 2011-11-24 at 07:29 +0000, McClintock Matthew-B29882 wrote:
> > On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > > hmmm I guess cross recipes are special they should not have been built
> > > under target recipes. Adding build arch to package name would be ok
> > > too but may be if they were built under directory of their own which
> > > was something like <build>-<host>-<target> then it would also solve
> > > the problem i think
> > 
> > I agree - this is the discussion I'm trying to start. ;)
> 
> It's certainly true that the way the cross recipes are done at the
> moment does suck.  Really, they should be built as primarily native and
> the target arch ought to just be encoded into ${PN} somehow, rather than
> the current arrangement of pretending that they are target recipes.
> (All the runtime bits are, or should be, packaged separately by either
> libgcc or gcc-runtime so they will already get the right PACKAGE_ARCH.)

yes building them under native build dir and suffixing with
build.host.arch would be way to go

> 
> There are some old (and probably rather bit-rotten) patches to do that
> in the pb/toolchain-desuck branch of oe-classic.  I'm not sure whether
> any of that stuff will apply to modern oe-core but the general principle
> ought still to be valid.
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Nov. 24, 2011, 6:08 p.m.
On Thu, 2011-11-24 at 10:03 -0800, Khem Raj wrote:
> On (24/11/11 10:54), Phil Blundell wrote:
> > On Thu, 2011-11-24 at 07:29 +0000, McClintock Matthew-B29882 wrote:
> > > On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > > > hmmm I guess cross recipes are special they should not have been built
> > > > under target recipes. Adding build arch to package name would be ok
> > > > too but may be if they were built under directory of their own which
> > > > was something like <build>-<host>-<target> then it would also solve
> > > > the problem i think
> > > 
> > > I agree - this is the discussion I'm trying to start. ;)
> > 
> > It's certainly true that the way the cross recipes are done at the
> > moment does suck.  Really, they should be built as primarily native and
> > the target arch ought to just be encoded into ${PN} somehow, rather than
> > the current arrangement of pretending that they are target recipes.
> > (All the runtime bits are, or should be, packaged separately by either
> > libgcc or gcc-runtime so they will already get the right PACKAGE_ARCH.)
> 
> yes building them under native build dir and suffixing with
> build.host.arch would be way to go

I don't think it's necessary to put all three components in the name,
and doing so would make it harder to construct the right string to go in
DEPENDS later.

PACKAGE_ARCH for native is already the host system, so you get that one
for free, and the build arch is (or ought to be) irrelevant as far as
the artifacts are concerned.  So I think it's just the target system
name that needs to be encoded into PN for gcc-cross and binutils-cross.

p.
Khem Raj - Nov. 24, 2011, 6:29 p.m.
On (24/11/11 18:08), Phil Blundell wrote:
> On Thu, 2011-11-24 at 10:03 -0800, Khem Raj wrote:
> > On (24/11/11 10:54), Phil Blundell wrote:
> > > On Thu, 2011-11-24 at 07:29 +0000, McClintock Matthew-B29882 wrote:
> > > > On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > > > > hmmm I guess cross recipes are special they should not have been built
> > > > > under target recipes. Adding build arch to package name would be ok
> > > > > too but may be if they were built under directory of their own which
> > > > > was something like <build>-<host>-<target> then it would also solve
> > > > > the problem i think
> > > > 
> > > > I agree - this is the discussion I'm trying to start. ;)
> > > 
> > > It's certainly true that the way the cross recipes are done at the
> > > moment does suck.  Really, they should be built as primarily native and
> > > the target arch ought to just be encoded into ${PN} somehow, rather than
> > > the current arrangement of pretending that they are target recipes.
> > > (All the runtime bits are, or should be, packaged separately by either
> > > libgcc or gcc-runtime so they will already get the right PACKAGE_ARCH.)
> > 
> > yes building them under native build dir and suffixing with
> > build.host.arch would be way to go
> 
> I don't think it's necessary to put all three components in the name,
> and doing so would make it harder to construct the right string to go in
> DEPENDS later.

yeah host in cross case would be useless since host = build we only need build and target
I thought of canadian builds

> 
> PACKAGE_ARCH for native is already the host system, so you get that one
> for free, and the build arch is (or ought to be) irrelevant as far as
> the artifacts are concerned.  So I think it's just the target system
> name that needs to be encoded into PN for gcc-cross and binutils-cross.
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
McClintock Matthew-B29882 - Nov. 24, 2011, 11:56 p.m.
On Wed, Nov 23, 2011 at 3:40 AM, Matthew McClintock <msm@freescale.com> wrote:
> +# we also add this to the PV so its clear in filenames
> +# that this is arch specific even though it's labeled as
> +# a target package
> +PV .= "+${BUILD_ARCH_EXPANDED}"

Seems like based on discussion this should be the following instead:

PN .= "-{BUILD_ARCH}-${TARGET_ARCH}"

-M
Richard Purdie - Nov. 25, 2011, 12:17 a.m.
On Thu, 2011-11-24 at 23:56 +0000, McClintock Matthew-B29882 wrote:
> On Wed, Nov 23, 2011 at 3:40 AM, Matthew McClintock <msm@freescale.com> wrote:
> > +# we also add this to the PV so its clear in filenames
> > +# that this is arch specific even though it's labeled as
> > +# a target package
> > +PV .= "+${BUILD_ARCH_EXPANDED}"
> 
> Seems like based on discussion this should be the following instead:
> 
> PN .= "-{BUILD_ARCH}-${TARGET_ARCH}"

What we really want is something like this in cross.bbclass:

MULTIMACH_TARGET_SYS = "${BUILD_ARCH}${BUILD_VENDOR}-${BUILD_OS}"
PN .= "-${TRANSLATED_TARGET_ARCH}"

so that WORKDIR gets changed. I've not tested what this does to the
build though.

Also, looking at sstate.bbclass it does:

    elif bb.data.inherits_class('cross', d):
        bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${TUNE_PKGARCH}", d), d)
        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d)

so it should be sticking BUILD_ARCH into the sstate file name directly.
This should mean you can't use 32 bit sstate files on a 64 bit system
and vice versa already?

Cheers,

Richard
McClintock Matthew-B29882 - Nov. 25, 2011, 1:52 a.m.
On Thu, Nov 24, 2011 at 6:17 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> This should mean you can't use 32 bit sstate files on a 64 bit system
> and vice versa already?

That would seem to be the case already:

SSTATE_PKG="/home/mattsm/git/poky/sstate-cache/sstate-gcc-cross-ppce5500-fsl-linux-4.6.1+svnr175454-r10-x86_64_ppce5500-2-${BB_TASKHASH}"

SSTATE_PKG="/home/mattsm/git/poky/sstate-cache/sstate-gcc-cross-ppce500mc-fsl-linux-4.6.1+svnr175454-r10-i686_ppce500mc-2-${BB_TASKHASH}"

So, I'm not 100% sure what is going on anymore...

-M
McClintock Matthew-B29882 - Nov. 28, 2011, 10:50 p.m.
On Thu, Nov 24, 2011 at 7:51 PM, Matthew McClintock <msm@freescale.com> wrote:
> On Thu, Nov 24, 2011 at 6:17 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> This should mean you can't use 32 bit sstate files on a 64 bit system
>> and vice versa already?
>
> That would seem to be the case already:
>
> SSTATE_PKG="/home/mattsm/git/poky/sstate-cache/sstate-gcc-cross-ppce5500-fsl-linux-4.6.1+svnr175454-r10-x86_64_ppce5500-2-${BB_TASKHASH}"
>
> SSTATE_PKG="/home/mattsm/git/poky/sstate-cache/sstate-gcc-cross-ppce500mc-fsl-linux-4.6.1+svnr175454-r10-i686_ppce500mc-2-${BB_TASKHASH}"
>
> So, I'm not 100% sure what is going on anymore...

For those interested my actual issue is related to linux header
symlinks from eglibc-initial pointing at invalid locations... which
causes gcc-cross-intermediate to fail. I'll submit a potential fix for
this shortly.

-M

Patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
index f7bcf30..ee42fa7 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@ 
 require gcc-common.inc
 
-PR = "r10"
+PR = "r11"
 
 # Third digit in PV should be incremented after a minor release
 # happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
index 5a796bc..9f6d6ad 100644
--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -10,3 +10,14 @@  do_compile () {
 	oe_runmake all-host all-target-libgcc
 }
 
+# gcc-cross is special since it builds a HOST binary on
+# as a TARGET recipe. This is a hack to pull in the
+# BUILD_ARCH to the recipe so the sstate-cache is
+# different if the HOST ARCH has changed. By expanding
+# right now we assure it's going to be in the sig
+BUILD_ARCH_EXPANDED := "${BUILD_ARCH}"
+
+# we also add this to the PV so its clear in filenames
+# that this is arch specific even though it's labeled as
+# a target package
+PV .= "+${BUILD_ARCH_EXPANDED}"