summaryrefslogtreecommitdiffstats
path: root/meta/recipes-extended
diff options
context:
space:
mode:
authorMark Hatle <mark.hatle@windriver.com>2013-08-09 18:41:05 -0500
committerRichard Purdie <richard.purdie@linuxfoundation.org>2013-08-13 23:06:01 +0100
commit0bc564af07c1bae8112f834a60aea3b72af7de13 (patch)
tree70361b122d64b0d74900cb67ebff64d5084a2291 /meta/recipes-extended
parentc8879e23ab19af1e74c09310d33d3c7c519f63b7 (diff)
downloadpoky-0bc564af07c1bae8112f834a60aea3b72af7de13.tar.gz
image.bbclass: Move runtime_mapping_rename to avoid conflict w/ multilib
[YOCTO #4993] Move the runtime_mapping_rename into a prefunc for the do_rootfs function. Otherwise doing it in the python section could occur BEFORE the multilib classes renaming. If the package 'b' is a kernel module, then lib32-b and b should both point to the same package. The runtime_mapping code will do this automatically. Before if you ran: bitbake lib32-<image> It may do: start PACKAGE_INSTALL (a b c) remap (a b c) MULTILIB naming (lib32-a lib32-b lib32-c) What we want is: start PACKAGE_INSTALL (a b c) MULTILIB naming (lib32-a lib32-b lib32-c) remap (lib32-a b lib32-c) (From OE-Core rev: 836662c9a9c175521dbcd29cdfc0a7c144d8770f) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-extended')
0 files changed, 0 insertions, 0 deletions