| Summary: | empty.c: code model not supported in 32bit mode error with lib32 image build | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Jiajun Xu <jiajun.xu> |
| Component: | meta-yocto | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | dongxiao.xu, ke.yu, lianhao.lu, mark.hatle, poky.bs.watcher, poky.watcher, sgw |
| Version: | unspecified | ||
| Target Milestone: | 1.1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Jiajun Xu
2011-08-10 22:43:20 UTC
There are some parts of the system we shouldn't extend to different multilibs, the kernel is one of them... This isn't a bug in the multilib system. The linux kernel can only be built with the "largest" endian available to the system. I.e. on x86_64, it must be built as x86_64. The remaining bug, if any, is simply a way to prevent certain packages from working in a multilib config. Simply raising SkipPackage in appropriate cases is likely the best solution. The kernel is specific enough that I'm happy for it to be coded against testing for inherit kernel or module-base and then picking the "larger" one. We'd probably have to code that 64 bit wins over 32 bit. I've done a POC patch as below. then the bitbake lib32-core-image-sato will fail in parsing as expected, since virtual/lib32-kernel is not available. so i wonder if it is acceptable? If so, how should we test the lib32-core-image-sato?
"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7dc9cc6..fbd567d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = "1"
KERNEL_IMAGETYPE ?= "zImage"
INITRAMFS_IMAGE ?= ""
INITRAMFS_TASK ?= ""
+NO_MULTILIB ?= "1"
python __anonymous () {
kerneltype = bb.data.getVar('KERNEL_IMAGETYPE', d, 1) or ''
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 6e1669f..34744cd 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -6,6 +6,9 @@ python multilib_virtclass_handler () {
variant = e.data.getVar("BBEXTENDVARIANT", True)
if cls != "multilib" or not variant:
return
+
+ if e.data.getVar("NO_MULTILIB", True) == "1":
+ raise bb.parse.SkipPackage("NO_MULTILIB is set")
override = ":virtclass-multilib-" + variant
"
I'm thinking we need something more along the lines of: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=7198e9962235b2d144c63c02823f9b46211c997a which raises the SkipParse error in the multilib cases and manipulates PROVIDES in the non-multilib case to include the multilib variants. The patch above is a work in progress though and I was only half way through writing it before travel interrupted the work. |