| 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
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 >
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
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 >
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
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
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 >
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
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
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.
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
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.
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
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
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
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
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}"
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(-)