Skip to contentSkip to conversation

module: build and clean hostprogs for each module

PATCH In review Darren Hart 2 participants 10 messages Mar 2, 2011 – Mar 7, 2011

lore
Share & tools
lore

Darren Hart

author
#0 lore raw

PATCH 1/2 module: build and clean hostprogs for each module

From: Darren Hart <[email protected]>

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 <[email protected]>
CC Gary Thomas <[email protected]>
---
 meta/classes/module.bbclass |   21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)
meta/classes/module.bbclass +20 -1
index d16d462..78f9b0a 100644
@@ -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 () {
Signature · 1 line
1.7.1
#1 lore raw
Quoted 8 lines · Darren Hart

From: Darren Hart<[email protected]>

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.

Quoted 7 lines

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<[email protected]>
CC Gary Thomas<[email protected]>

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?

Quoted 43 lines
---
  meta/classes/module.bbclass |   21 ++++++++++++++++++++-
  1 files changed, 20 insertions(+), 1 deletions(-)
meta/classes/module.bbclass +20 -1
index d16d462..78f9b0a 100644
@@ -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 () {
Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#2 lore raw
Quoted 14 lines · Gary Thomas
Quoted 13 lines · Darren Hart

From: Darren Hart<[email protected]>

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

Quoted 8 lines
Quoted 2 lines
Signed-off-by Darren Hart<[email protected]>
CC Gary Thomas<[email protected]>

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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
author
#3 lore raw
Quoted 24 lines · Gary Thomas
Quoted 23 lines · Gary Thomas
Quoted 10 lines · Darren Hart

From: Darren Hart<[email protected]>

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.

Quoted 8 lines

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<[email protected]>
CC Gary Thomas<[email protected]>

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.

Quoted 8 lines
Quoted 2 lines

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.

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#4 lore raw
Quoted 34 lines · Darren Hart
Quoted 24 lines · Gary Thomas
Quoted 23 lines · Gary Thomas
Quoted 10 lines · Darren Hart

From: Darren Hart<[email protected]>

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.

Quoted 8 lines

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<[email protected]>
CC Gary Thomas<[email protected]>

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.

Quoted 8 lines
Quoted 2 lines

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.

Quoted 8 lines

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)

Quoted 8 lines
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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
author
#5 lore raw
Quoted 49 lines · Gary Thomas
Quoted 48 lines · Darren Hart
Quoted 28 lines · Gary Thomas
Quoted 18 lines · Gary Thomas
Quoted 17 lines · Darren Hart

From: Darren Hart<[email protected]>

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

Quoted 8 lines
Quoted 2 lines
Signed-off-by Darren Hart<[email protected]>
CC Gary Thomas<[email protected]>

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?

Quoted 6 lines

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:

Quoted 9 lines
Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 1 line

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

Quoted 15 lines
Quoted 14 lines

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.

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
author
#6 lore raw
Quoted 85 lines · Darren Hart
Quoted 53 lines · Gary Thomas
Quoted 52 lines · Darren Hart
Quoted 29 lines · Gary Thomas
Quoted 19 lines · Gary Thomas
Quoted 18 lines · Darren Hart

From: Darren Hart<[email protected]>

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

Quoted 8 lines
Quoted 2 lines
Signed-off-by Darren Hart<[email protected]>
CC Gary Thomas<[email protected]>

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?

Quoted 7 lines

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:

Quoted 9 lines
Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 3 lines

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

Quoted 33 lines
Quoted 3 lines

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

Quoted 17 lines
Quoted 16 lines

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.

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#7 lore raw
Quoted 93 lines · Darren Hart
Quoted 87 lines · Darren Hart
Quoted 55 lines · Gary Thomas
Quoted 54 lines · Darren Hart
Quoted 29 lines · Gary Thomas
Quoted 19 lines · Gary Thomas
Quoted 18 lines · Darren Hart

From: Darren Hart<[email protected]>

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

Quoted 8 lines
Quoted 2 lines
Signed-off-by Darren Hart<[email protected]>
CC Gary Thomas<[email protected]>

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?

Quoted 7 lines

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:

Quoted 9 lines
Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 64 lines

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

Quoted 33 lines
Quoted 3 lines

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

Quoted 17 lines
Quoted 16 lines

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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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"

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"

author
#8 lore raw
Quoted 113 lines · Gary Thomas
Quoted 112 lines · Darren Hart
Quoted 98 lines · Darren Hart
Quoted 67 lines · Gary Thomas
Quoted 58 lines · Darren Hart
Quoted 34 lines · Gary Thomas
Quoted 23 lines · Gary Thomas
Quoted 22 lines · Darren Hart

From: Darren Hart<[email protected]>

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

Quoted 9 lines
Quoted 2 lines
Signed-off-by Darren Hart<[email protected]>
CC Gary Thomas<[email protected]>

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?

Quoted 9 lines

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
Quoted 7 lines

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

Quoted 7 lines

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.

Quoted 3 lines

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

Quoted 5 lines

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

Quoted 8 lines
Quoted 2 lines

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

Quoted 85 lines

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.

Quoted 79 lines

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

Quoted 35 lines
Quoted 3 lines

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

Quoted 19 lines
Quoted 18 lines

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.

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
author
#9 lore raw
In reply to Gary Thomas
Quoted 15 lines · Gary Thomas
Quoted 14 lines · Darren Hart

From: Darren Hart<[email protected]>

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

Quoted 7 lines
Quoted 2 lines
Signed-off-by Darren Hart<[email protected]>
CC Gary Thomas<[email protected]>

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

Quoted 46 lines
Quoted 45 lines

---
meta/classes/module.bbclass | 21 ++++++++++++++++++++-

1 files changed, 20 insertions(+), 1 deletions(-)
meta/classes/module.bbclass +0 -0
index d16d462..78f9b0a 100644
@@ -3,6 +3,15 @@ DEPENDS += "virtual/kernel"

inherit module-base

meta/classes/module.bbclass +9 -0
+# 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} \

meta/classes/module.bbclass +0 -0
@@ -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

meta/classes/module.bbclass +7 -0
+}
+
+# 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 () {

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel