* [PATCH 1/2] module: build and clean hostprogs for each module @ 2011-03-02 18:00 Darren Hart 2011-03-03 16:50 ` Gary Thomas 0 siblings, 1 reply; 10+ messages in thread From: Darren Hart @ 2011-03-02 18:00 UTC (permalink / raw) To: poky; +Cc: Darren Hart From: Darren Hart <dvhart@linux.intel.com> This fixes [BUGID #241] The kernel hostprogs are built for the host architecture. They should not be deployed with to the target, and they should not be included in an sstate package which might get reused on a host of a different architecture. As we don't build many out-of-tree modules, this patch takes the approach of building the hostprogs as part of the module compile process with a do_compile_prepend() routine in module.bbclass. To ensure the hostprogs don't contaminate the build, they are removed in do_install_append(). Signed-off-by: Darren Hart <dvhart@linux.intel.com> CC: Gary Thomas <gary@mlbassoc.com> --- meta/classes/module.bbclass | 21 ++++++++++++++++++++- 1 files changed, 20 insertions(+), 1 deletions(-) diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass index d16d462..78f9b0a 100644 --- a/meta/classes/module.bbclass +++ b/meta/classes/module.bbclass @@ -3,6 +3,15 @@ DEPENDS += "virtual/kernel" inherit module-base +# Ensure the hostprogs are available for module compilation +module_do_compile_prepend() { + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ + -C ${STAGING_KERNEL_DIR} clean SUBDIRS=scripts + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ + -C ${STAGING_KERNEL_DIR} scripts +} + module_do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ @@ -15,7 +24,17 @@ module_do_compile() { module_do_install() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS - oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" CC="${KERNEL_CC}" LD="${KERNEL_LD}" modules_install + oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \ + KERNEL_SRC=${STAGING_KERNEL_DIR} \ + CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ + modules_install +} + +# Remove the hostprogs from the STAGING_KERNEL_DIR +module_do_install_append() { + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ + -C ${STAGING_KERNEL_DIR} clean SUBDIRS=scripts } pkg_postinst_append () { -- 1.7.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-02 18:00 [PATCH 1/2] module: build and clean hostprogs for each module Darren Hart @ 2011-03-03 16:50 ` Gary Thomas 2011-03-03 16:59 ` Gary Thomas 2011-03-04 4:36 ` Darren Hart 0 siblings, 2 replies; 10+ messages in thread From: Gary Thomas @ 2011-03-03 16:50 UTC (permalink / raw) To: Darren Hart; +Cc: poky On 03/02/2011 11:00 AM, Darren Hart wrote: > From: Darren Hart<dvhart@linux.intel.com> > > This fixes [BUGID #241] > > The kernel hostprogs are built for the host architecture. They should not > be deployed with to the target, and they should not be included in an sstate > package which might get reused on a host of a different architecture. > > As we don't build many out-of-tree modules, this patch takes the approach > of building the hostprogs as part of the module compile process with a > do_compile_prepend() routine in module.bbclass. To ensure the hostprogs > don't contaminate the build, they are removed in do_install_append(). > > Signed-off-by: Darren Hart<dvhart@linux.intel.com> > CC: Gary Thomas<gary@mlbassoc.com> Sadly, this doesn't seem to work for me. I don't see any indication in run.do_compile that the extra steps were added at all. Will it matter if my recipe overrides the do_compile() method? > --- > meta/classes/module.bbclass | 21 ++++++++++++++++++++- > 1 files changed, 20 insertions(+), 1 deletions(-) > > diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass > index d16d462..78f9b0a 100644 > --- a/meta/classes/module.bbclass > +++ b/meta/classes/module.bbclass > @@ -3,6 +3,15 @@ DEPENDS += "virtual/kernel" > > inherit module-base > > +# Ensure the hostprogs are available for module compilation > +module_do_compile_prepend() { > + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ > + -C ${STAGING_KERNEL_DIR} clean SUBDIRS=scripts > + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ > + -C ${STAGING_KERNEL_DIR} scripts > +} > + > module_do_compile() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ > @@ -15,7 +24,17 @@ module_do_compile() { > > module_do_install() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > - oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" CC="${KERNEL_CC}" LD="${KERNEL_LD}" modules_install > + oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \ > + KERNEL_SRC=${STAGING_KERNEL_DIR} \ > + CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > + modules_install > +} > + > +# Remove the hostprogs from the STAGING_KERNEL_DIR > +module_do_install_append() { > + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ > + -C ${STAGING_KERNEL_DIR} clean SUBDIRS=scripts > } > > pkg_postinst_append () { -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-03 16:50 ` Gary Thomas @ 2011-03-03 16:59 ` Gary Thomas 2011-03-04 4:39 ` Darren Hart 2011-03-04 4:36 ` Darren Hart 1 sibling, 1 reply; 10+ messages in thread From: Gary Thomas @ 2011-03-03 16:59 UTC (permalink / raw) To: Darren Hart; +Cc: poky On 03/03/2011 09:50 AM, Gary Thomas wrote: > On 03/02/2011 11:00 AM, Darren Hart wrote: >> From: Darren Hart<dvhart@linux.intel.com> >> >> This fixes [BUGID #241] >> >> The kernel hostprogs are built for the host architecture. They should not >> be deployed with to the target, and they should not be included in an sstate >> package which might get reused on a host of a different architecture. >> >> As we don't build many out-of-tree modules, this patch takes the approach >> of building the hostprogs as part of the module compile process with a >> do_compile_prepend() routine in module.bbclass. To ensure the hostprogs >> don't contaminate the build, they are removed in do_install_append(). >> >> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >> CC: Gary Thomas<gary@mlbassoc.com> > > Sadly, this doesn't seem to work for me. I don't see any indication in > run.do_compile that the extra steps were added at all. > > Will it matter if my recipe overrides the do_compile() method? > Also, when you tested this, what was your target MACHINE (in particular, was the target a different architecture than the build host?) I ask because I tried to just manually insert the compile_prepend() functions into my recipe and it ended up trying to build host tools (that's what the fuss is all about) using the target toolchain. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-03 16:59 ` Gary Thomas @ 2011-03-04 4:39 ` Darren Hart 2011-03-04 11:44 ` Gary Thomas 0 siblings, 1 reply; 10+ messages in thread From: Darren Hart @ 2011-03-04 4:39 UTC (permalink / raw) To: Gary Thomas; +Cc: poky On 03/03/2011 08:59 AM, Gary Thomas wrote: > On 03/03/2011 09:50 AM, Gary Thomas wrote: >> On 03/02/2011 11:00 AM, Darren Hart wrote: >>> From: Darren Hart<dvhart@linux.intel.com> >>> >>> This fixes [BUGID #241] >>> >>> The kernel hostprogs are built for the host architecture. They should >>> not >>> be deployed with to the target, and they should not be included in an >>> sstate >>> package which might get reused on a host of a different architecture. >>> >>> As we don't build many out-of-tree modules, this patch takes the >>> approach >>> of building the hostprogs as part of the module compile process with a >>> do_compile_prepend() routine in module.bbclass. To ensure the hostprogs >>> don't contaminate the build, they are removed in do_install_append(). >>> >>> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >>> CC: Gary Thomas<gary@mlbassoc.com> >> >> Sadly, this doesn't seem to work for me. I don't see any indication in >> run.do_compile that the extra steps were added at all. >> >> Will it matter if my recipe overrides the do_compile() method? >> > > Also, when you tested this, what was your target MACHINE (in particular, > was the target a different architecture than the build host?) I ask because > I tried to just manually insert the compile_prepend() functions into my > recipe and it ended up trying to build host tools (that's what the fuss > is all about) using the target toolchain. I made some modifications to avoid a Race that RP pointed out (just removed the cleans from the module.bbclass since they weren't necessary anyway). With this, I set my MACHINE to beagleboard and built minimal. You can see from the following that hostprogs were build for the host and the module for the target: dvhart@rage:build-beagleboard$ file ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped dvhart@rage:build-beagleboard$ file ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped I'm going to do a beagleboard boot test, but if that works I'll be resending these changes to close BUG 241 as they work on both qemux86 and beagleboard using hello-world-mod which uses a very typical out-of-tree kernel module Make setup. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-04 4:39 ` Darren Hart @ 2011-03-04 11:44 ` Gary Thomas 2011-03-04 20:33 ` Darren Hart 0 siblings, 1 reply; 10+ messages in thread From: Gary Thomas @ 2011-03-04 11:44 UTC (permalink / raw) To: Darren Hart; +Cc: poky On 03/03/2011 09:39 PM, Darren Hart wrote: > On 03/03/2011 08:59 AM, Gary Thomas wrote: >> On 03/03/2011 09:50 AM, Gary Thomas wrote: >>> On 03/02/2011 11:00 AM, Darren Hart wrote: >>>> From: Darren Hart<dvhart@linux.intel.com> >>>> >>>> This fixes [BUGID #241] >>>> >>>> The kernel hostprogs are built for the host architecture. They should >>>> not >>>> be deployed with to the target, and they should not be included in an >>>> sstate >>>> package which might get reused on a host of a different architecture. >>>> >>>> As we don't build many out-of-tree modules, this patch takes the >>>> approach >>>> of building the hostprogs as part of the module compile process with a >>>> do_compile_prepend() routine in module.bbclass. To ensure the hostprogs >>>> don't contaminate the build, they are removed in do_install_append(). >>>> >>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >>>> CC: Gary Thomas<gary@mlbassoc.com> >>> >>> Sadly, this doesn't seem to work for me. I don't see any indication in >>> run.do_compile that the extra steps were added at all. >>> >>> Will it matter if my recipe overrides the do_compile() method? >>> >> >> Also, when you tested this, what was your target MACHINE (in particular, >> was the target a different architecture than the build host?) I ask because >> I tried to just manually insert the compile_prepend() functions into my >> recipe and it ended up trying to build host tools (that's what the fuss >> is all about) using the target toolchain. > > I made some modifications to avoid a Race that RP pointed out (just removed the cleans from the module.bbclass since they weren't necessary anyway). With this, I set my MACHINE to > beagleboard and built minimal. You can see from the following that hostprogs were build for the host and the module for the target: > > dvhart@rage:build-beagleboard$ file > ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep > > ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep: > ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped Why are you looking in ${KERNEL_SRC}? It may not exist (think rm_work) when your module gets built. The example recipe I have uses ${STAGING_KERNEL_DIR} something like this: make -C ${STAGING_KERNEL_DIR} M=src Also, if you look at the run.do_compile script for your module recipe, is there any indication that the compile_prepend() stuff was even added? I don't see it in mine (yes, it inherits module) > > dvhart@rage:build-beagleboard$ file ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko > ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko: ELF 32-bit LSB relocatable, ARM, version 1 > (SYSV), not stripped > > I'm going to do a beagleboard boot test, but if that works I'll be resending these changes to close BUG 241 as they work on both qemux86 and beagleboard using hello-world-mod which > uses a very typical out-of-tree kernel module Make setup. > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-04 11:44 ` Gary Thomas @ 2011-03-04 20:33 ` Darren Hart 2011-03-04 21:31 ` Darren Hart 0 siblings, 1 reply; 10+ messages in thread From: Darren Hart @ 2011-03-04 20:33 UTC (permalink / raw) To: Gary Thomas; +Cc: poky On 03/04/2011 03:44 AM, Gary Thomas wrote: > On 03/03/2011 09:39 PM, Darren Hart wrote: >> On 03/03/2011 08:59 AM, Gary Thomas wrote: >>> On 03/03/2011 09:50 AM, Gary Thomas wrote: >>>> On 03/02/2011 11:00 AM, Darren Hart wrote: >>>>> From: Darren Hart<dvhart@linux.intel.com> >>>>> >>>>> This fixes [BUGID #241] >>>>> >>>>> The kernel hostprogs are built for the host architecture. They should >>>>> not >>>>> be deployed with to the target, and they should not be included in an >>>>> sstate >>>>> package which might get reused on a host of a different architecture. >>>>> >>>>> As we don't build many out-of-tree modules, this patch takes the >>>>> approach >>>>> of building the hostprogs as part of the module compile process with a >>>>> do_compile_prepend() routine in module.bbclass. To ensure the >>>>> hostprogs >>>>> don't contaminate the build, they are removed in do_install_append(). >>>>> >>>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >>>>> CC: Gary Thomas<gary@mlbassoc.com> >>>> >>>> Sadly, this doesn't seem to work for me. I don't see any indication in >>>> run.do_compile that the extra steps were added at all. >>>> >>>> Will it matter if my recipe overrides the do_compile() method? >>>> >>> >>> Also, when you tested this, what was your target MACHINE (in particular, >>> was the target a different architecture than the build host?) I ask >>> because >>> I tried to just manually insert the compile_prepend() functions into my >>> recipe and it ended up trying to build host tools (that's what the fuss >>> is all about) using the target toolchain. >> >> I made some modifications to avoid a Race that RP pointed out (just >> removed the cleans from the module.bbclass since they weren't >> necessary anyway). With this, I set my MACHINE to >> beagleboard and built minimal. You can see from the following that >> hostprogs were build for the host and the module for the target: >> >> dvhart@rage:build-beagleboard$ file >> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep >> >> >> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep: >> >> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >> linked (uses shared libs), for GNU/Linux 2.6.15, not stripped > > Why are you looking in ${KERNEL_SRC}? It may not exist (think rm_work) > when your module gets built. > > The example recipe I have uses ${STAGING_KERNEL_DIR} something like this: > make -C ${STAGING_KERNEL_DIR} M=src > module.bbclass passes KERNEL_SRC=${STAGING_KERNEL_DIR} to the module's Makefile. I don't use STAGING_KERNEL_DIR in the hello-mod Makefile as I wanted the Makefile to exemplary of external modules, and not poky specific. > Also, if you look at the run.do_compile script for your module recipe, is > there any indication that the compile_prepend() stuff was even added? I do see the compile_prepend() code prepended to the do_compile code: unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS oe_runmake CC="arm-poky-linux-gnueabi-gcc " LD="arm-poky-linux-gnueabi-ld --sysroot=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard " AR="arm-poky-linux-gnueabi-ar " \ -C /home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel scripts Hrm.... but looking at that, that's the target compiler... not the host compiler... so why on earth did this work.... grumble. Some more investigation remains it seems... > I don't see it in mine (yes, it inherits module) Even though there is something up with the script build above, you should be seeing it in run.do_compile. Is this recipe something you can share? Also, have you tried from a clean build? I ran into various (strange) problems because I wasn't cleaning the right tasks/recipes/etc. I think your problem is different, but might have a similar cause. -- Darren > >> >> dvhart@rage:build-beagleboard$ file >> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko >> >> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko: >> ELF 32-bit LSB relocatable, ARM, version 1 >> (SYSV), not stripped >> >> I'm going to do a beagleboard boot test, but if that works I'll be >> resending these changes to close BUG 241 as they work on both qemux86 >> and beagleboard using hello-world-mod which >> uses a very typical out-of-tree kernel module Make setup. >> > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-04 20:33 ` Darren Hart @ 2011-03-04 21:31 ` Darren Hart 2011-03-06 16:21 ` Gary Thomas 0 siblings, 1 reply; 10+ messages in thread From: Darren Hart @ 2011-03-04 21:31 UTC (permalink / raw) To: Gary Thomas; +Cc: poky On 03/04/2011 12:33 PM, Darren Hart wrote: > On 03/04/2011 03:44 AM, Gary Thomas wrote: >> On 03/03/2011 09:39 PM, Darren Hart wrote: >>> On 03/03/2011 08:59 AM, Gary Thomas wrote: >>>> On 03/03/2011 09:50 AM, Gary Thomas wrote: >>>>> On 03/02/2011 11:00 AM, Darren Hart wrote: >>>>>> From: Darren Hart<dvhart@linux.intel.com> >>>>>> >>>>>> This fixes [BUGID #241] >>>>>> >>>>>> The kernel hostprogs are built for the host architecture. They should >>>>>> not >>>>>> be deployed with to the target, and they should not be included in an >>>>>> sstate >>>>>> package which might get reused on a host of a different architecture. >>>>>> >>>>>> As we don't build many out-of-tree modules, this patch takes the >>>>>> approach >>>>>> of building the hostprogs as part of the module compile process >>>>>> with a >>>>>> do_compile_prepend() routine in module.bbclass. To ensure the >>>>>> hostprogs >>>>>> don't contaminate the build, they are removed in do_install_append(). >>>>>> >>>>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >>>>>> CC: Gary Thomas<gary@mlbassoc.com> >>>>> >>>>> Sadly, this doesn't seem to work for me. I don't see any indication in >>>>> run.do_compile that the extra steps were added at all. >>>>> >>>>> Will it matter if my recipe overrides the do_compile() method? >>>>> >>>> >>>> Also, when you tested this, what was your target MACHINE (in >>>> particular, >>>> was the target a different architecture than the build host?) I ask >>>> because >>>> I tried to just manually insert the compile_prepend() functions into my >>>> recipe and it ended up trying to build host tools (that's what the fuss >>>> is all about) using the target toolchain. >>> >>> I made some modifications to avoid a Race that RP pointed out (just >>> removed the cleans from the module.bbclass since they weren't >>> necessary anyway). With this, I set my MACHINE to >>> beagleboard and built minimal. You can see from the following that >>> hostprogs were build for the host and the module for the target: >>> >>> dvhart@rage:build-beagleboard$ file >>> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep >>> >>> >>> >>> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep: >>> >>> >>> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >>> linked (uses shared libs), for GNU/Linux 2.6.15, not stripped >> >> Why are you looking in ${KERNEL_SRC}? It may not exist (think rm_work) >> when your module gets built. >> >> The example recipe I have uses ${STAGING_KERNEL_DIR} something like this: >> make -C ${STAGING_KERNEL_DIR} M=src >> > > module.bbclass passes KERNEL_SRC=${STAGING_KERNEL_DIR} to the module's > Makefile. > > I don't use STAGING_KERNEL_DIR in the hello-mod Makefile as I wanted the > Makefile to exemplary of external modules, and not poky specific. > > >> Also, if you look at the run.do_compile script for your module recipe, is >> there any indication that the compile_prepend() stuff was even added? > > I do see the compile_prepend() code prepended to the do_compile code: > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > oe_runmake CC="arm-poky-linux-gnueabi-gcc " > LD="arm-poky-linux-gnueabi-ld > --sysroot=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard > " AR="arm-poky-linux-gnueabi-ar " \ > -C > /home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel > scripts > > Hrm.... but looking at that, that's the target compiler... not the host > compiler... so why on earth did this work.... grumble. Some more > investigation remains it seems... Actually, this isn't a problem. For the compilation of hostprogs, the kernel Make system uses HOSTCC, not CC. From log.do_compile: make -C /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux O=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/. scripts make[1]: Entering directory `/home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux' HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc GEN /home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/Makefile HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf While the module itself builds with: make -C /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux O=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/. LD /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/built-in.o CC [M] /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.o Building modules, stage 2. MODPOST 1 modules CC /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.mod.o LD [M] /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.ko Things are working as intended for the hello-mod recipe. -- Darren > > > > I don't see it in mine (yes, it inherits module) > > Even though there is something up with the script build above, you > should be seeing it in run.do_compile. Is this recipe something you can > share? Also, have you tried from a clean build? I ran into various > (strange) problems because I wasn't cleaning the right > tasks/recipes/etc. I think your problem is different, but might have a > similar cause. > > -- > Darren > >> >>> >>> dvhart@rage:build-beagleboard$ file >>> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko >>> >>> >>> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko: >>> >>> ELF 32-bit LSB relocatable, ARM, version 1 >>> (SYSV), not stripped >>> >>> I'm going to do a beagleboard boot test, but if that works I'll be >>> resending these changes to close BUG 241 as they work on both qemux86 >>> and beagleboard using hello-world-mod which >>> uses a very typical out-of-tree kernel module Make setup. >>> >> > > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-04 21:31 ` Darren Hart @ 2011-03-06 16:21 ` Gary Thomas 2011-03-07 22:16 ` Darren Hart 0 siblings, 1 reply; 10+ messages in thread From: Gary Thomas @ 2011-03-06 16:21 UTC (permalink / raw) To: Darren Hart; +Cc: poky [-- Attachment #1: Type: text/plain, Size: 7850 bytes --] On 03/04/11 14:31, Darren Hart wrote: > On 03/04/2011 12:33 PM, Darren Hart wrote: >> On 03/04/2011 03:44 AM, Gary Thomas wrote: >>> On 03/03/2011 09:39 PM, Darren Hart wrote: >>>> On 03/03/2011 08:59 AM, Gary Thomas wrote: >>>>> On 03/03/2011 09:50 AM, Gary Thomas wrote: >>>>>> On 03/02/2011 11:00 AM, Darren Hart wrote: >>>>>>> From: Darren Hart<dvhart@linux.intel.com> >>>>>>> >>>>>>> This fixes [BUGID #241] >>>>>>> >>>>>>> The kernel hostprogs are built for the host architecture. They should >>>>>>> not >>>>>>> be deployed with to the target, and they should not be included in an >>>>>>> sstate >>>>>>> package which might get reused on a host of a different architecture. >>>>>>> >>>>>>> As we don't build many out-of-tree modules, this patch takes the >>>>>>> approach >>>>>>> of building the hostprogs as part of the module compile process >>>>>>> with a >>>>>>> do_compile_prepend() routine in module.bbclass. To ensure the >>>>>>> hostprogs >>>>>>> don't contaminate the build, they are removed in do_install_append(). >>>>>>> >>>>>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >>>>>>> CC: Gary Thomas<gary@mlbassoc.com> >>>>>> >>>>>> Sadly, this doesn't seem to work for me. I don't see any indication in >>>>>> run.do_compile that the extra steps were added at all. >>>>>> >>>>>> Will it matter if my recipe overrides the do_compile() method? >>>>>> >>>>> >>>>> Also, when you tested this, what was your target MACHINE (in >>>>> particular, >>>>> was the target a different architecture than the build host?) I ask >>>>> because >>>>> I tried to just manually insert the compile_prepend() functions into my >>>>> recipe and it ended up trying to build host tools (that's what the fuss >>>>> is all about) using the target toolchain. >>>> >>>> I made some modifications to avoid a Race that RP pointed out (just >>>> removed the cleans from the module.bbclass since they weren't >>>> necessary anyway). With this, I set my MACHINE to >>>> beagleboard and built minimal. You can see from the following that >>>> hostprogs were build for the host and the module for the target: >>>> >>>> dvhart@rage:build-beagleboard$ file >>>> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep >>>> >>>> >>>> >>>> >>>> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep: >>>> >>>> >>>> >>>> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >>>> linked (uses shared libs), for GNU/Linux 2.6.15, not stripped >>> >>> Why are you looking in ${KERNEL_SRC}? It may not exist (think rm_work) >>> when your module gets built. >>> >>> The example recipe I have uses ${STAGING_KERNEL_DIR} something like this: >>> make -C ${STAGING_KERNEL_DIR} M=src >>> >> >> module.bbclass passes KERNEL_SRC=${STAGING_KERNEL_DIR} to the module's >> Makefile. >> >> I don't use STAGING_KERNEL_DIR in the hello-mod Makefile as I wanted the >> Makefile to exemplary of external modules, and not poky specific. >> >> >>> Also, if you look at the run.do_compile script for your module recipe, is >>> there any indication that the compile_prepend() stuff was even added? >> >> I do see the compile_prepend() code prepended to the do_compile code: >> >> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >> oe_runmake CC="arm-poky-linux-gnueabi-gcc " >> LD="arm-poky-linux-gnueabi-ld >> --sysroot=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard >> " AR="arm-poky-linux-gnueabi-ar " \ >> -C >> /home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel >> scripts >> >> Hrm.... but looking at that, that's the target compiler... not the host >> compiler... so why on earth did this work.... grumble. Some more >> investigation remains it seems... > > > Actually, this isn't a problem. For the compilation of hostprogs, the kernel Make system uses HOSTCC, not CC. From log.do_compile: > > make -C > /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux > O=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/. scripts This sure looks like it's using the kernel source tree, not the staging tree. If you run with rm_work and/or sstate caching, that directory may not exist! My example (which was lifted fro OE) uses the kernel _staging_ directory, which should exist. Recipe attached - I'm not sure how much use it is as it as a boat-load of dependencies which are not germane to this issue. > make[1]: Entering directory > `/home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux' > > HOSTCC scripts/basic/fixdep > HOSTCC scripts/basic/docproc > GEN /home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/Makefile > HOSTCC scripts/kconfig/conf.o > HOSTCC scripts/kconfig/kxgettext.o > HOSTCC scripts/kconfig/zconf.tab.o > HOSTLD scripts/kconfig/conf > > While the module itself builds with: > > make -C > /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux > O=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/. > LD /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/built-in.o > CC [M] /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.o > Building modules, stage 2. > MODPOST 1 modules > CC /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.mod.o > LD [M] /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.ko > > > Things are working as intended for the hello-mod recipe. > > -- > Darren > >> >> >> > I don't see it in mine (yes, it inherits module) >> >> Even though there is something up with the script build above, you >> should be seeing it in run.do_compile. Is this recipe something you can >> share? Also, have you tried from a clean build? I ran into various >> (strange) problems because I wasn't cleaning the right >> tasks/recipes/etc. I think your problem is different, but might have a >> similar cause. >> >> -- >> Darren >> >>> >>>> >>>> dvhart@rage:build-beagleboard$ file >>>> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko >>>> >>>> >>>> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko: >>>> >>>> ELF 32-bit LSB relocatable, ARM, version 1 >>>> (SYSV), not stripped >>>> >>>> I'm going to do a beagleboard boot test, but if that works I'll be >>>> resending these changes to close BUG 241 as they work on both qemux86 >>>> and beagleboard using hello-world-mod which >>>> uses a very typical out-of-tree kernel module Make setup. >>>> >>> >> >> > > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ [-- Attachment #2: ti-linuxutils.inc --] [-- Type: text/plain, Size: 3407 bytes --] DESCRIPTION = "MFP Linux utils for TI ARM/DSP processors" SECTION = "devel" LICENSE = "GPLv2,BSD" BASE_SRC_URI = "http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/${PV}/exports" SRC_URI = "${BASE_SRC_URI}/linuxutils_${PV}.tar.gz " S = "${WORKDIR}/linuxutils_${PV}" require ti-paths.inc require ti-staging.inc #This is a kernel module, don't set PR directly MACHINE_KERNEL_PR_append = "d" inherit module do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS case ${SOC_FAMILY} in dm365) modules="cmem edma irq";; omap3) modules="cmem sdma";; dm355) modules="cmem edma irq";; *) modules="cmem" esac # Insure host tools are available # HORRIBLE HACK # Sadly, I can't see how to automate these builds since the normal # way to do it using the Makefile ends up building target executables # not useful host tools. # make CROSS_COMPILE= -C ${STAGING_KERNEL_DIR}/scripts/basic fixdep # make CROSS_COMPILE= -C ${STAGING_KERNEL_DIR} SUBDIRS=scripts cd ${STAGING_KERNEL_DIR}/scripts/basic cc -o fixdep fixdep.c cd ${STAGING_KERNEL_DIR}/scripts/mod cc -o modpost modpost.c file2alias.c sumversion.c cd ${STAGING_KERNEL_DIR}/scripts/genksyms cc -o genksyms genksyms.c parse.c lex.c for module in $modules ; do cd ${S}/packages/ti/sdo/linuxutils/$module make \ LINUXKERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" \ MVTOOL_PREFIX="${TARGET_PREFIX}" \ UCTOOL_PREFIX="${TARGET_PREFIX}" \ clean debug release done } do_install () { install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/drivers/dsp # Install CMEM for module in $(find ${S}/packages/ti/sdo/linuxutils/ -name "*.ko") ; do install -m 0755 $module ${D}/lib/modules/${KERNEL_VERSION}/kernel/drivers/dsp done cd ${S}/packages/ti/sdo/linuxutils/cmem/apps make \ LINUXKERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" \ MVTOOL_PREFIX="${TARGET_PREFIX}" \ UCTOOL_PREFIX="${TARGET_PREFIX}" \ EXEC_DIR="${D}${installdir}/ti-linuxutils-app/cmem-app" \ install # Install EDMA if [ ${SOC_FAMILY} == "dm365" ] ; then cd ${S}/packages/ti/sdo/linuxutils/edma/apps make \ LINUXKERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" \ MVTOOL_PREFIX="${TARGET_PREFIX}" \ UCTOOL_PREFIX="${TARGET_PREFIX}" \ EXEC_DIR="${D}${installdir}/ti-linuxutils-app/edma-app" \ install fi # stage tree - other packages may need this install -d ${D}${LINUXUTILS_INSTALL_DIR_RECIPE} cp -pPrf ${S}/* ${D}${LINUXUTILS_INSTALL_DIR_RECIPE} } PACKAGES =+ " ti-cmem-module \ ti-sdma-module \ ti-edma-module \ ti-irq-module \ ti-linuxutils-app" FILES_ti-cmem-module = "/lib/modules/${KERNEL_VERSION}/kernel/drivers/dsp/cmem*.ko" FILES_ti-sdma-module = "/lib/modules/${KERNEL_VERSION}/kernel/drivers/dsp/sdma*.ko" FILES_ti-edma-module = "/lib/modules/${KERNEL_VERSION}/kernel/drivers/dsp/edma*.ko" FILES_ti-irq-module = "/lib/modules/${KERNEL_VERSION}/kernel/drivers/dsp/irq*.ko" FILES_ti-linuxutils-app = "${installdir}/ti-linuxutils-app/*/*" INSANE_SKIP_ti-linuxutils-app = "True" PACKAGE_STRIP = "no" [-- Attachment #3: ti-linuxutils_2.26.01.02.bb --] [-- Type: text/plain, Size: 344 bytes --] require ti-linuxutils.inc LIC_FILES_CHKSUM = " \ file://gpl_2.0.txt;md5=1298794fc2eed3df92a89f3c9d317440 \ " SRC_URI += "file://linuxutils-BKL-fix-2.patch" PE = "1" PV = "2_26_01_02" SRC_URI[md5sum] = "70b4918bc35c1bcfef34d6ba3fbce0c8" SRC_URI[sha256sum] = "51266dd928f8d629cd417c869789a6c0d596612120f165619119cbaadfd66ee2" ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-06 16:21 ` Gary Thomas @ 2011-03-07 22:16 ` Darren Hart 0 siblings, 0 replies; 10+ messages in thread From: Darren Hart @ 2011-03-07 22:16 UTC (permalink / raw) To: Gary Thomas; +Cc: poky On 03/06/2011 08:21 AM, Gary Thomas wrote: > On 03/04/11 14:31, Darren Hart wrote: >> On 03/04/2011 12:33 PM, Darren Hart wrote: >>> On 03/04/2011 03:44 AM, Gary Thomas wrote: >>>> On 03/03/2011 09:39 PM, Darren Hart wrote: >>>>> On 03/03/2011 08:59 AM, Gary Thomas wrote: >>>>>> On 03/03/2011 09:50 AM, Gary Thomas wrote: >>>>>>> On 03/02/2011 11:00 AM, Darren Hart wrote: >>>>>>>> From: Darren Hart<dvhart@linux.intel.com> >>>>>>>> >>>>>>>> This fixes [BUGID #241] >>>>>>>> >>>>>>>> The kernel hostprogs are built for the host architecture. They >>>>>>>> should >>>>>>>> not >>>>>>>> be deployed with to the target, and they should not be included >>>>>>>> in an >>>>>>>> sstate >>>>>>>> package which might get reused on a host of a different >>>>>>>> architecture. >>>>>>>> >>>>>>>> As we don't build many out-of-tree modules, this patch takes the >>>>>>>> approach >>>>>>>> of building the hostprogs as part of the module compile process >>>>>>>> with a >>>>>>>> do_compile_prepend() routine in module.bbclass. To ensure the >>>>>>>> hostprogs >>>>>>>> don't contaminate the build, they are removed in >>>>>>>> do_install_append(). >>>>>>>> >>>>>>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >>>>>>>> CC: Gary Thomas<gary@mlbassoc.com> >>>>>>> >>>>>>> Sadly, this doesn't seem to work for me. I don't see any >>>>>>> indication in >>>>>>> run.do_compile that the extra steps were added at all. >>>>>>> >>>>>>> Will it matter if my recipe overrides the do_compile() method? >>>>>>> >>>>>> >>>>>> Also, when you tested this, what was your target MACHINE (in >>>>>> particular, >>>>>> was the target a different architecture than the build host?) I ask >>>>>> because >>>>>> I tried to just manually insert the compile_prepend() functions >>>>>> into my >>>>>> recipe and it ended up trying to build host tools (that's what the >>>>>> fuss >>>>>> is all about) using the target toolchain. >>>>> >>>>> I made some modifications to avoid a Race that RP pointed out (just >>>>> removed the cleans from the module.bbclass since they weren't >>>>> necessary anyway). With this, I set my MACHINE to >>>>> beagleboard and built minimal. You can see from the following that >>>>> hostprogs were build for the host and the module for the target: >>>>> >>>>> dvhart@rage:build-beagleboard$ file >>>>> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep: >>>>> >>>>> >>>>> >>>>> >>>>> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >>>>> linked (uses shared libs), for GNU/Linux 2.6.15, not stripped >>>> >>>> Why are you looking in ${KERNEL_SRC}? It may not exist (think rm_work) >>>> when your module gets built. >>>> >>>> The example recipe I have uses ${STAGING_KERNEL_DIR} something like >>>> this: >>>> make -C ${STAGING_KERNEL_DIR} M=src >>>> >>> >>> module.bbclass passes KERNEL_SRC=${STAGING_KERNEL_DIR} to the module's >>> Makefile. >>> >>> I don't use STAGING_KERNEL_DIR in the hello-mod Makefile as I wanted the >>> Makefile to exemplary of external modules, and not poky specific. >>> >>> >>>> Also, if you look at the run.do_compile script for your module >>>> recipe, is >>>> there any indication that the compile_prepend() stuff was even added? >>> >>> I do see the compile_prepend() code prepended to the do_compile code: >>> >>> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >>> oe_runmake CC="arm-poky-linux-gnueabi-gcc " >>> LD="arm-poky-linux-gnueabi-ld >>> --sysroot=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard >>> >>> " AR="arm-poky-linux-gnueabi-ar " \ >>> -C >>> /home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel >>> >>> scripts >>> >>> Hrm.... but looking at that, that's the target compiler... not the host >>> compiler... so why on earth did this work.... grumble. Some more >>> investigation remains it seems... >> >> >> Actually, this isn't a problem. For the compilation of hostprogs, the >> kernel Make system uses HOSTCC, not CC. From log.do_compile: >> >> make -C >> /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux >> >> O=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/. >> scripts > > This sure looks like it's using the kernel source tree, not the staging > tree. If you run with rm_work > and/or sstate caching, that directory may not exist! My example (which > was lifted fro OE) uses the > kernel _staging_ directory, which should exist. Ah, the problem is that while I pass STAGING_KERNEL_DIR, the Makefile there just redirects the make to the kernel source directory. What we appear to need is something along the lines of: $ make O=${PN}-modules_prepare modules_prepare which runs 'prepare' and 'scripts'. Unfortunately, this still has a symlink to the source dir in the output dir - probably for things like vmlinux, etc. I'm looking into how we can best accomplish this without the recipe becoming too fragile to maintain from kernel version to kernel version. -- Darren > > Recipe attached - I'm not sure how much use it is as it as a boat-load > of dependencies > which are not germane to this issue. > >> make[1]: Entering directory >> `/home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux' >> >> >> HOSTCC scripts/basic/fixdep >> HOSTCC scripts/basic/docproc >> GEN >> /home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/Makefile >> >> HOSTCC scripts/kconfig/conf.o >> HOSTCC scripts/kconfig/kxgettext.o >> HOSTCC scripts/kconfig/zconf.tab.o >> HOSTLD scripts/kconfig/conf >> >> While the module itself builds with: >> >> make -C >> /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux >> >> O=/home/dvhart/source/poky.git/build-beagleboard/tmp/sysroots/beagleboard/kernel/. >> >> LD >> /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/built-in.o >> >> CC [M] >> /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.o >> >> Building modules, stage 2. >> MODPOST 1 modules >> CC >> /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.mod.o >> >> LD [M] >> /home/dvhart/source/poky.git/build-beagleboard/tmp/work/beagleboard-poky-linux-gnueabi/hello-mod-0.1-r0/hello.ko >> >> >> >> Things are working as intended for the hello-mod recipe. >> >> -- >> Darren >> >>> >>> >>> > I don't see it in mine (yes, it inherits module) >>> >>> Even though there is something up with the script build above, you >>> should be seeing it in run.do_compile. Is this recipe something you can >>> share? Also, have you tried from a clean build? I ran into various >>> (strange) problems because I wasn't cleaning the right >>> tasks/recipes/etc. I think your problem is different, but might have a >>> similar cause. >>> >>> -- >>> Darren >>> >>>> >>>>> >>>>> dvhart@rage:build-beagleboard$ file >>>>> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko >>>>> >>>>> >>>>> >>>>> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko: >>>>> >>>>> >>>>> ELF 32-bit LSB relocatable, ARM, version 1 >>>>> (SYSV), not stripped >>>>> >>>>> I'm going to do a beagleboard boot test, but if that works I'll be >>>>> resending these changes to close BUG 241 as they work on both qemux86 >>>>> and beagleboard using hello-world-mod which >>>>> uses a very typical out-of-tree kernel module Make setup. >>>>> >>>> >>> >>> >> >> > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] module: build and clean hostprogs for each module 2011-03-03 16:50 ` Gary Thomas 2011-03-03 16:59 ` Gary Thomas @ 2011-03-04 4:36 ` Darren Hart 1 sibling, 0 replies; 10+ messages in thread From: Darren Hart @ 2011-03-04 4:36 UTC (permalink / raw) To: Gary Thomas; +Cc: poky On 03/03/2011 08:50 AM, Gary Thomas wrote: > On 03/02/2011 11:00 AM, Darren Hart wrote: >> From: Darren Hart<dvhart@linux.intel.com> >> >> This fixes [BUGID #241] >> >> The kernel hostprogs are built for the host architecture. They should not >> be deployed with to the target, and they should not be included in an >> sstate >> package which might get reused on a host of a different architecture. >> >> As we don't build many out-of-tree modules, this patch takes the approach >> of building the hostprogs as part of the module compile process with a >> do_compile_prepend() routine in module.bbclass. To ensure the hostprogs >> don't contaminate the build, they are removed in do_install_append(). >> >> Signed-off-by: Darren Hart<dvhart@linux.intel.com> >> CC: Gary Thomas<gary@mlbassoc.com> > > Sadly, this doesn't seem to work for me. I don't see any indication in > run.do_compile that the extra steps were added at all. > > Will it matter if my recipe overrides the do_compile() method? No, if you override do_compile(), the do_compile_prepend() from module.bbclass will still run - provided of course that you: inherit module -- Darren > >> --- >> meta/classes/module.bbclass | 21 ++++++++++++++++++++- >> 1 files changed, 20 insertions(+), 1 deletions(-) >> >> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass >> index d16d462..78f9b0a 100644 >> --- a/meta/classes/module.bbclass >> +++ b/meta/classes/module.bbclass >> @@ -3,6 +3,15 @@ DEPENDS += "virtual/kernel" >> >> inherit module-base >> >> +# Ensure the hostprogs are available for module compilation >> +module_do_compile_prepend() { >> + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >> + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ >> + -C ${STAGING_KERNEL_DIR} clean SUBDIRS=scripts >> + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ >> + -C ${STAGING_KERNEL_DIR} scripts >> +} >> + >> module_do_compile() { >> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >> oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ >> @@ -15,7 +24,17 @@ module_do_compile() { >> >> module_do_install() { >> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >> - oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" CC="${KERNEL_CC}" >> LD="${KERNEL_LD}" modules_install >> + oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \ >> + KERNEL_SRC=${STAGING_KERNEL_DIR} \ >> + CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ >> + modules_install >> +} >> + >> +# Remove the hostprogs from the STAGING_KERNEL_DIR >> +module_do_install_append() { >> + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >> + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ >> + -C ${STAGING_KERNEL_DIR} clean SUBDIRS=scripts >> } >> >> pkg_postinst_append () { > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-03-07 22:18 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-02 18:00 [PATCH 1/2] module: build and clean hostprogs for each module Darren Hart 2011-03-03 16:50 ` Gary Thomas 2011-03-03 16:59 ` Gary Thomas 2011-03-04 4:39 ` Darren Hart 2011-03-04 11:44 ` Gary Thomas 2011-03-04 20:33 ` Darren Hart 2011-03-04 21:31 ` Darren Hart 2011-03-06 16:21 ` Gary Thomas 2011-03-07 22:16 ` Darren Hart 2011-03-04 4:36 ` Darren Hart
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.