Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
On 11/25/2011 02:57 PM, Darren Hart wrote: On 11/24/2011 12:05 AM, Darren Hart wrote: Add a recipe to build the GRUB efi images. This recipe is written as a native recipe as the resulting GRUB utils are required to assemble the final image. Rather than build a native and a target recipe (and increase build times), this recipe builds the utils for the host and passes an appropriate --target argument to the GRUB configure script to build the modules for the target arch. The only output of this recipe is an EFI image in the deploy directory. The grub-help list came through with an alternative approach: ./configure CC=powerpc-linux-gcc --host=ppc-linux-gnu --target=i386 --with-platform=pc TARGET_CC=i386-linux-gcc This would allow for building on a host of arch ppc for a target of arch i386. Would it be preferable then to build this as a target package and manipuate the configure flags to use the BUILD_CC ? I presume a similar PN rename would be desirable to account for the HOST component of the build as I used here for the TARGET on the -native version? I have been working on trying to get this working as a target recipe. I've resolved a number of issues, but something is still biting me and I haven't been able to sort out what. I would really appreciate a few more sets of eyes on this. I have pushed my dvhart/efi/dev branch to poky-contrib for reference: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev When building this recipe, the mkimage task fails with the grub-mkimage command segfaulting. I can build with the same ./configure command and using the Yocto 1.1 x86_64-i586 toolchain for the TARGET_CC and the mkimage succeeds. The configure command is: ./configure --build=x86_64-linux --host=x86_64-linux --target=i586-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --with-libtool-sysroot=/build/poky/n450/tmp/sysroots/n450 CC=gcc TARGET_CC=i586-poky-linux-gcc --with-platform=efi --enable-efiemu=no --disable-grub-mkfont --program-prefix='' --enable-nls The make output from building manually vs. within bitbake is nearly identical with a couple minor path changes for the cross toolchain. The bitbake make also prints more errors, including the following for the grub-mkimage target (which is the one that segfaults). gcc -DHAVE_CONFIG_H -I. -Wall -W -I./include -DGRUB_UTIL=1 -DGRUB_LIBDIR=\/usr/lib/grub\ -DLOCALEDIR=\/usr/share/locale\ -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=I386_EFI -DGRUB_FILE=\util/grub-mkimage.c\ -I. -I. -I. -I. -I./include -I./include -I./grub-core/gnulib -I./grub-core/gnulib -DGRUB_PKGLIBROOTDIR=\/usr/lib/''grub\-Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -MT util/grub_mkimage-grub-mkimage.o -MD -MP -MF util/.deps-util/grub_mkimage-grub-mkimage.Tpo -c -o util/grub_mkimage-grub-mkimage.o `test -f 'util/grub-mkimage.c' || echo './'`util/grub-mkimage.c util/grub-mkimage.c: In function 'generate_image': util/grub-mkimage.c:665:11: warning: passing argument 2 of 'load_image32' from incompatible pointer type [enabled by default] util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *' util/grub-mkimage.c:665:11: warning: passing argument 3 of 'load_image32' from incompatible pointer type [enabled by default] util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *' util/grub-mkimage.c:669:11: warning: passing argument 2 of 'load_image64' from incompatible pointer type [enabled by default] util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *' util/grub-mkimage.c:669:11: warning: passing argument 3 of 'load_image64' from incompatible pointer type [enabled by default] util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *' The recipe follows for your reference and for inline comments. Any thoughts on why this might be failing? Is there are better way to go about trying to build this as a target recipe? grub-efi_1.99.bb SUMMARY = GRUB2 is the next-generation GRand Unified Bootloader DESCRIPTION = GRUB2 is the next generaion of a GPLed bootloader \ intended to unify bootloading across x86 operating systems. In \ addition to loading the Linux kernel, it implements the Multiboot \ standard, which allows for flexible loading of multiple boot images. \ This recipe builds an EFI binary for the target. It does not install \ or package anything, it only deploys a target-arch GRUB EFI image. HOMEPAGE = http://www.gnu.org/software/grub/; SECTION = bootloaders PRIORITY = optional LICENSE = GPLv3 LIC_FILES_CHKSUM =
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
Op 29 nov. 2011, om 09:03 heeft Darren Hart het volgende geschreven: On 11/25/2011 02:57 PM, Darren Hart wrote: On 11/24/2011 12:05 AM, Darren Hart wrote: Add a recipe to build the GRUB efi images. This recipe is written as a native recipe as the resulting GRUB utils are required to assemble the final image. Rather than build a native and a target recipe (and increase build times), this recipe builds the utils for the host and passes an appropriate --target argument to the GRUB configure script to build the modules for the target arch. The only output of this recipe is an EFI image in the deploy directory. The grub-help list came through with an alternative approach: ./configure CC=powerpc-linux-gcc --host=ppc-linux-gnu --target=i386 --with-platform=pc TARGET_CC=i386-linux-gcc This would allow for building on a host of arch ppc for a target of arch i386. Would it be preferable then to build this as a target package and manipuate the configure flags to use the BUILD_CC ? I presume a similar PN rename would be desirable to account for the HOST component of the build as I used here for the TARGET on the -native version? I have been working on trying to get this working as a target recipe. I've resolved a number of issues, but something is still biting me and I haven't been able to sort out what. I would really appreciate a few more sets of eyes on this. I have pushed my dvhart/efi/dev branch to poky-contrib for reference: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev When building this recipe This is against poky, so I can't build it. If it was against OE-core, like one would expect on the OE-core mailing list, I could build it. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
On 11/29/2011 12:22 AM, Koen Kooi wrote: Op 29 nov. 2011, om 09:03 heeft Darren Hart het volgende geschreven: On 11/25/2011 02:57 PM, Darren Hart wrote: On 11/24/2011 12:05 AM, Darren Hart wrote: Add a recipe to build the GRUB efi images. This recipe is written as a native recipe as the resulting GRUB utils are required to assemble the final image. Rather than build a native and a target recipe (and increase build times), this recipe builds the utils for the host and passes an appropriate --target argument to the GRUB configure script to build the modules for the target arch. The only output of this recipe is an EFI image in the deploy directory. The grub-help list came through with an alternative approach: ./configure CC=powerpc-linux-gcc --host=ppc-linux-gnu --target=i386 --with-platform=pc TARGET_CC=i386-linux-gcc This would allow for building on a host of arch ppc for a target of arch i386. Would it be preferable then to build this as a target package and manipuate the configure flags to use the BUILD_CC ? I presume a similar PN rename would be desirable to account for the HOST component of the build as I used here for the TARGET on the -native version? I have been working on trying to get this working as a target recipe. I've resolved a number of issues, but something is still biting me and I haven't been able to sort out what. I would really appreciate a few more sets of eyes on this. I have pushed my dvhart/efi/dev branch to poky-contrib for reference: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev When building this recipe This is against poky, so I can't build it. If it was against OE-core, like one would expect on the OE-core mailing list, I could build it. OK, fair enough. git://git.infradead.org/srv/git/users/dvhart/oe-core.git dvhart/efi/dev I just fixed up the patch series - untested. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
On 11/24/2011 12:05 AM, Darren Hart wrote:
Add a recipe to build the GRUB efi images. This recipe is written as
a native recipe as the resulting GRUB utils are required to assemble
the final image. Rather than build a native and a target recipe (and
increase build times), this recipe builds the utils for the host and
passes an appropriate --target argument to the GRUB configure script
to build the modules for the target arch. The only output of this
recipe is an EFI image in the deploy directory.
The grub-help list came through with an alternative approach:
./configure CC=powerpc-linux-gcc --host=ppc-linux-gnu --target=i386
--with-platform=pc TARGET_CC=i386-linux-gcc
This would allow for building on a host of arch ppc for a target of arch
i386.
Would it be preferable then to build this as a target package and
manipuate the configure flags to use the BUILD_CC ? I presume a similar
PN rename would be desirable to account for the HOST component of the
build as I used here for the TARGET on the -native version?
--
Darren
Care is taken to ensure changing targets will force a rebuild of this
native recipe by including the target arch in the PN.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/recipes-bsp/grub/grub-efi-native_1.99.bb | 74
+
1 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-bsp/grub/grub-efi-native_1.99.bb
diff --git a/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
new file mode 100644
index 000..3c52ec9
--- /dev/null
+++ b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
@@ -0,0 +1,74 @@
+SUMMARY = GRUB2 is the next-generation GRand Unified Bootloader
+
+DESCRIPTION = GRUB2 is the next generaion of a GPLed bootloader \
+intended to unify bootloading across x86 operating systems. In \
+addition to loading the Linux kernel, it implements the Multiboot \
+standard, which allows for flexible loading of multiple boot images. \
+This recipe builds an EFI binary for the target. It does not install \
+or package anything, it only deploys a target-arch GRUB EFI image.
+
+HOMEPAGE = http://www.gnu.org/software/grub/;
+SECTION = bootloaders
+PRIORITY = optional
+
+LICENSE = GPLv3
+LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
+
+# FIXME: We should be able to optionally drop freetype as a dependency
+DEPENDS = help2man-native
+RDEPENDS_${PN} = diffutils freetype
+PR = r1
+
+# Native packages do not normally rebuild when the target changes.
+# Ensure this is built once per HOST-TARGET pair.
+PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
+
+SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz;
+
+SRC_URI[md5sum] = ca9f2a2d571b57fc5c53212d1d22e2b5
+SRC_URI[sha256sum] =
b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff
+
+COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
+
+S = ${WORKDIR}/grub-${PV}
+
+# Determine the target arch for the grub modules before the native class
+# clobbers TARGET_ARCH.
+ORIG_TARGET_ARCH := ${TARGET_ARCH}
+python __anonymous () {
+import re
+target = d.getVar('ORIG_TARGET_ARCH', True)
+if target == x86_64:
+grubtarget = 'x86_64'
+grubimage = bootx64.efi
+elif re.match('i.86', target):
+grubtarget = 'i386'
+grubimage = bootia32.efi
+else:
+raise bb.parse.SkipPackage(grub-efi is incompatible with target %s
% target)
+d.setVar(GRUB_TARGET, grubtarget)
+d.setVar(GRUB_IMAGE, grubimage)
+}
+
+inherit autotools
+inherit gettext
+inherit native
+inherit deploy
+
+EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
+--target=${GRUB_TARGET} --enable-efiemu=no
--program-prefix=''
+
+do_mkimage() {
+ ./grub-mkimage -p / -d ./grub-core/ \
+-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
+boot linux fat serial part_msdos normal
+}
+addtask mkimage after do_compile before do_install
+
+do_deploy() {
+ install -m 644 ${S}/${GRUB_IMAGE} ${DEPLOYDIR}
+}
+addtask deploy after do_install before do_build
+
+do_install[noexec] = 1
+do_populate_sysroot[noexec] = 1
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
Add a recipe to build the GRUB efi images. This recipe is written as
a native recipe as the resulting GRUB utils are required to assemble
the final image. Rather than build a native and a target recipe (and
increase build times), this recipe builds the utils for the host and
passes an appropriate --target argument to the GRUB configure script
to build the modules for the target arch. The only output of this
recipe is an EFI image in the deploy directory.
Care is taken to ensure changing targets will force a rebuild of this
native recipe by including the target arch in the PN.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/recipes-bsp/grub/grub-efi-native_1.99.bb | 74 +
1 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-bsp/grub/grub-efi-native_1.99.bb
diff --git a/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
new file mode 100644
index 000..3c52ec9
--- /dev/null
+++ b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
@@ -0,0 +1,74 @@
+SUMMARY = GRUB2 is the next-generation GRand Unified Bootloader
+
+DESCRIPTION = GRUB2 is the next generaion of a GPLed bootloader \
+intended to unify bootloading across x86 operating systems. In \
+addition to loading the Linux kernel, it implements the Multiboot \
+standard, which allows for flexible loading of multiple boot images. \
+This recipe builds an EFI binary for the target. It does not install \
+or package anything, it only deploys a target-arch GRUB EFI image.
+
+HOMEPAGE = http://www.gnu.org/software/grub/;
+SECTION = bootloaders
+PRIORITY = optional
+
+LICENSE = GPLv3
+LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
+
+# FIXME: We should be able to optionally drop freetype as a dependency
+DEPENDS = help2man-native
+RDEPENDS_${PN} = diffutils freetype
+PR = r1
+
+# Native packages do not normally rebuild when the target changes.
+# Ensure this is built once per HOST-TARGET pair.
+PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
+
+SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz;
+
+SRC_URI[md5sum] = ca9f2a2d571b57fc5c53212d1d22e2b5
+SRC_URI[sha256sum] =
b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff
+
+COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
+
+S = ${WORKDIR}/grub-${PV}
+
+# Determine the target arch for the grub modules before the native class
+# clobbers TARGET_ARCH.
+ORIG_TARGET_ARCH := ${TARGET_ARCH}
+python __anonymous () {
+import re
+target = d.getVar('ORIG_TARGET_ARCH', True)
+if target == x86_64:
+grubtarget = 'x86_64'
+grubimage = bootx64.efi
+elif re.match('i.86', target):
+grubtarget = 'i386'
+grubimage = bootia32.efi
+else:
+raise bb.parse.SkipPackage(grub-efi is incompatible with target %s %
target)
+d.setVar(GRUB_TARGET, grubtarget)
+d.setVar(GRUB_IMAGE, grubimage)
+}
+
+inherit autotools
+inherit gettext
+inherit native
+inherit deploy
+
+EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
+--target=${GRUB_TARGET} --enable-efiemu=no --program-prefix=''
+
+do_mkimage() {
+ ./grub-mkimage -p / -d ./grub-core/ \
+ -O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
+ boot linux fat serial part_msdos normal
+}
+addtask mkimage after do_compile before do_install
+
+do_deploy() {
+ install -m 644 ${S}/${GRUB_IMAGE} ${DEPLOYDIR}
+}
+addtask deploy after do_install before do_build
+
+do_install[noexec] = 1
+do_populate_sysroot[noexec] = 1
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven: Add a recipe to build the GRUB efi images. This recipe is written as a native recipe as the resulting GRUB utils are required to assemble the final image. Rather than build a native and a target recipe (and increase build times), That's a false dilemma. If you write it as a regular recipe with BBCLASSEXTEND=native your buildtime doesn't increase and you leave open the option of adding more BBCLASSEXTENDS if someone wants to ship it in an SDK. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote: Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven: Add a recipe to build the GRUB efi images. This recipe is written as a native recipe as the resulting GRUB utils are required to assemble the final image. Rather than build a native and a target recipe (and increase build times), That's a false dilemma. If you write it as a regular recipe with BBCLASSEXTEND=native your buildtime doesn't increase That isn't true, if you build a target and a native version your build time does increase. Using BBCLASSEXTEND does improve parsing time over having two separate recipes though. and you leave open the option of adding more BBCLASSEXTENDS if someone wants to ship it in an SDK. I did talk with Darren about why the recipe is the way it is and there are some pretty nasty issues with the way grub builds itself. I'm therefore ok with this as a version 1 and we can see whether there are any issues that result which need us to rethink the way the recipe is constructed. Its currently behaving very like the way the binutils/gcc cross recipes will end up (see the separate thread with Matthew) Perhaps it should be called grub-efi-cross even if it uses native.bbclass. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
On 11/24/2011 03:26 AM, Richard Purdie wrote:
On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:
Add a recipe to build the GRUB efi images. This recipe is written as
a native recipe as the resulting GRUB utils are required to assemble
the final image. Rather than build a native and a target recipe (and
increase build times),
That's a false dilemma. If you write it as a regular recipe with
BBCLASSEXTEND=native your buildtime doesn't increase
That isn't true, if you build a target and a native version your build
time does increase. Using BBCLASSEXTEND does improve parsing time over
having two separate recipes though.
Right, while it isn't a huge project to build, I didn't want to
contribute to the expanding build time unnecessarily.
and you leave open the option of adding more BBCLASSEXTENDS if
someone wants to ship it in an SDK.
I think the right thing to do here is to modify the origin grub recipe
to build with the efi platform enabled if we want to ship the binaries
on the TARGET. This recipe doesn't build the grub tools for deployment,
it builds the target bootloader binary image for the boot media. That's
the distinction I'm going with anyway.
I did talk with Darren about why the recipe is the way it is and there
are some pretty nasty issues with the way grub builds itself. I'm
therefore ok with this as a version 1 and we can see whether there are
any issues that result which need us to rethink the way the recipe is
constructed.
Its currently behaving very like the way the binutils/gcc cross recipes
will end up (see the separate thread with Matthew) Perhaps it should be
called grub-efi-cross even if it uses native.bbclass.
If you prefer I can change it, I don't have a strong preference for the
name. That would end up as grub-efi-${TRANSLATED_TARGET_ARCH}-cross
after the PN adjustment then?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
Op 24 nov. 2011, om 12:26 heeft Richard Purdie het volgende geschreven: On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote: Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven: Add a recipe to build the GRUB efi images. This recipe is written as a native recipe as the resulting GRUB utils are required to assemble the final image. Rather than build a native and a target recipe (and increase build times), That's a false dilemma. If you write it as a regular recipe with BBCLASSEXTEND=native your buildtime doesn't increase That isn't true, if you build a target and a native version your build time does increase. Using BBCLASSEXTEND does improve parsing time over having two separate recipes though. Are you really saying that 'bitbake grub-native' will build both versions if you use BBCLASSEXTEND!?!?! If not, it remains a false dilemma. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2011 08:51 AM, Koen Kooi wrote: Op 24 nov. 2011, om 12:26 heeft Richard Purdie het volgende geschreven: On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote: Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven: Add a recipe to build the GRUB efi images. This recipe is written as a native recipe as the resulting GRUB utils are required to assemble the final image. Rather than build a native and a target recipe (and increase build times), That's a false dilemma. If you write it as a regular recipe with BBCLASSEXTEND=native your buildtime doesn't increase That isn't true, if you build a target and a native version your build time does increase. Using BBCLASSEXTEND does improve parsing time over having two separate recipes though. Are you really saying that 'bitbake grub-native' will build both versions if you use BBCLASSEXTEND!?!?! If not, it remains a false dilemma. No, that isn't it. Because of the way grub builds, you need the utils in HOST_ARCH and the grub modules in TARGET_ARCH. Grub has a monolithic build system, so in order to do this with BBCLASSEXTEND, we would need to have grub-efi depend on grub-efi-native so that the final do_mkimage task could use the -native version of grub-mkimage to assemble the target-built modules into a final binary. This approach builds grub natively and sets the --target to the TARGET_ARCH so the modules are built for the target. This is why I'm making the distinction between build the grub tools for deployment and building the grub efi boot image. The approach to each is different, and this recipe generates the boot image for the target. - -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOznttAAoJEKbMaAwKp364dG0H/0tScwNt0pc9gHDXDELdhCvp JGJ8soO+yWgksG9o/p077oysd7HMm24Tq//m7FuRzgm0D2JymYwPwdLe06mA1ARs BpwtvltUW5SLaWzJVeamxeNn5cDpdIcyaa904BdS2Ink/alZgTdoV60qh9LvElIh P70Pb/GeV/Po5OLALmnYuEV39JPnRxz7RfaXr7qU/0e0JVGKxXa/hrBp8ZgzpYI4 WvGns2LrZRPi/Fp93Vc312NfZYa2y/s9H8ji+B2Nvdza99Zo9y4xtWSf9bDRn+4J 04Kw/CFUe4GqXrIoBATLvm8LmcS/fLaqtVY5Ewz5bSnPFRvXyYApmmNvWpy5hGs= =LaXk -END PGP SIGNATURE- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
