linux/poky.git/meta/classes/qemu.bbclass, branch python3

meta/classes/qemu.bbclass: set -cpu of ppce5500/ppce6500 to e500mc

2016-04-15T05:59:43+00:00

The e5500 and e6500 cpu types are not supported by native qemu, set the value of -cpu to e500mc. Without this change, build will fail for packages which use qemuwrapper in compile phase due to the following error. | Unable to find CPU definition e.g. gobject-introspection (From OE-Core rev: e06c5c5447350049ebd1a6245fc2dd2608b265e5) Signed-off-by: Zhenhua Luo Signed-off-by: Richard Purdie

qemu.bbclass: add qemu_wrapper_cmdline()

2016-03-09T17:00:28+00:00

The class had qemu_run_binary() which was not suitable for gobject-introspection, as it required the name of the binary to run. qemu_wrapper_cmdline() returns just the command line string needed to run binaries, and does not require the binary name. (From OE-Core rev: 0b68f0632312392cbd20bfcb9ed4895cfc9883ff) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

qemu.bbclass: clarify QEMU_EXTRAOPTIONS

2016-01-30T11:37:01+00:00

QEMU_EXTRAOPTIONS is a way to add PACKAGE_ARCH specific options to the qemu_run_binary qemu commandline. The base QEMU_EXTRAOPTIONS variable (ie without a PACKAGE_ARCH suffix) is not used, so defining it, either directly or via an over-ride has no effect. Although previously an over-ride for _armv7a was used, it did nothing for most armv7a builds, which typically use PACKAGE_ARCH values such as "cortexa9hf-neon". In practice this worked OK since without a -cpu option, qemu-arm will default to emulating a CPU which supports all required architecture levels. qemu-arm (v2.5.0) with no -cpu option has been confirmed to successfully run binaries built for armv7ve. (From OE-Core rev: 62b25b3489b44969e4adad657daebfaffdb4de56) Signed-off-by: Andre McCurdy Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

qemu.bbclass: fix vardeps of QEMU_OPTIONS

2015-11-24T15:55:41+00:00

The variable name for QEMU_EXTRAOPTIONS is constructed programmatically, so we need an explicit variable dependency, otherwise changes to it won't cause e.g. qemuwrapper-cross to be rebuilt. (From OE-Core rev: 7740f214fffd6278f801899fc5e45f5720cbb544) Signed-off-by: Christopher Larson Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

qemu.bbclass: correct the fsl ppc QEMU_EXTRAOPTIONS

2015-11-24T15:55:41+00:00

These need to be based on PACKAGE_ARCH rather than TARGET_ARCH, as we aren't using overrides for this. (From OE-Core rev: 46f41df60491990dc41f0514f63b304ac51b67d1) Signed-off-by: Christopher Larson Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

qemu/libc-package: Fix qemu option handling

2014-12-05T18:01:08+00:00

The 'overrides' here are PACKAGE_ARCH based and hence not overrides as such and the _append wasn't working in many cases. This adjusts the code to use PACKAGE_ARCH as the accessor and ensures the variables work as expected. This fixes various segfaults and ensures postinsts run at build time rather than on the target system. The bug was introduced in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7efad8a1b56df6ee07c12ad360c0493d7b1d6d23. (From OE-Core rev: 219e793907406eabf632e784e3a11ab9acb77cfb) Signed-off-by: Richard Purdie Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

qemu.bbclass: add -r ${OLDEST_KERNEL} parameter

2014-09-10T10:33:25+00:00

* in some cases (e.g. with external toolchain which doesn't respect our reasonably old version set in OLDEST_KERNEL) it's possible to have libc which requires newer kernel than what we have on builders, qemu supports -r param to use different uname than what's returned by host system. * change qemu_run_binary to pass -r ${OLDEST_KERNEL} and add the same to QEMU_OPTIONS which are used by qemuwrapper-cross * maybe we should eventually convert all qemu_run_binary usages always include qemuwrapper-cross dependency and always call qemu through that (it seems very strange that qemu_target_binary is called from qemuwrapper and for allarch recipes it can return qemu-allarch as qemu binary). qemu_run_binary is used by: meta/classes/gtk-immodules-cache.bbclass: ${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-$maj_ver.0')} \ meta/classes/qemu.bbclass:def qemu_run_binary(data, rootfs_path, binary): meta/recipes-core/systemd/systemd_213.bb: ${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} hwdb --update \ meta/recipes-graphics/pango/pango.inc: ${@qemu_run_binary(d, '$D','${bindir}/${MLPREFIX}pango-querymodules')} \ and qemuwrapper directly by: scripts/postinst-intercepts/update_font_cache:PSEUDO_UNLOAD=1 qemuwrapper -L $D -E LD_LIBRARY_PATH=$D/${libdir}:$D/${base_libdir}\ scripts/postinst-intercepts/update_pixbuf_cache:PSEUDO_UNLOAD=1 qemuwrapper -L $D -E LD_LIBRARY_PATH=$D/${libdir}:$D/${base_libdir}\ (From OE-Core rev: 1f0bff320077f4d9f2ee51096a1438e8cae9dd0d) Signed-off-by: Martin Jansa Signed-off-by: Saul Wold Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake.conf/qemu: Move QEMU_OPTIONS to qemu.bbclass

2014-06-14T07:43:56+00:00

The QEMU_OPTIONS variables belong in qemu.bbclass so move them there. The only users of them inherit qemu.bbclass. There is no point in pushing these into every recipe. (From OE-Core rev: 5824293de37919e89f60192836997281933e23d6) Signed-off-by: Richard Purdie

Revert "qemu.bbclass: Use the correct qemu binary in multilib cases"

2013-04-29T13:45:10+00:00

This reverts commit 9f5a6f89d9f4a6c7bed3b163e6eaa764d762f523. The reason for reverting this is: * qemuwrapper has now a fallback method; * when using multilib, calling qemu_target_binary from recipes would always point to the qemu binary corresponding to the machine architecture. Hence, postinstalls needing to use qemu would call the wrong qemu user emulation binary; (From OE-Core rev: 15408466515cec7cbb4c394aa203c87b6165f884) Signed-off-by: Laurentiu Palcu Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

postinst-intercepts, qemu.bbclass: fix segfaults in postinstalls

2013-04-10T11:56:52+00:00

Postinstalls that use qemu are throwing a segmentation fault when building for qemux86-64 on a 64bit host (it might also happen for qemux86 if building on a 32bit host but I didn't test). It looks like qemu looks for ld.so.cache which is not found because it is generated after rootfs_(rpm|ipk|deb)_do_rootfs is called and then it tries to load libraries from the default paths (which are the host's). In order to avoid this, pass the LD_LIBRARY_PATH explicitly to the target's dynamic loader. (From OE-Core rev: 48e8b613b3f5c7b1d917bf3147606d44072ce49e) Signed-off-by: Laurentiu Palcu Signed-off-by: Richard Purdie