After some investigation on the debian buildfarm, we can see in the build/tmp/work/x86_64-linux/qemu-system-native/4.2.0-r0/temp/log.do_configure "libnfs support yes". If we comment in poky/meta/recipes-devtools/qemu/qemu.inc all the prepend do_configure_prepend_class-native(), we obtain "libnfs support no". The function do_configure_prepend_class-native, as written in commentaries, is to find sdl. But we see now it adds more than just the sdl support.
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday 28 May 2020 03:17, Andre McCurdy <armccu...@gmail.com> wrote: > On Wed, May 27, 2020 at 5:29 AM vygu via lists.openembedded.org > vygu=protonmail...@lists.openembedded.org wrote: > > > Hello, > > Since the zeus serie (also with dunfell), we observe an issue with runqemu > > when we share the sstate-cache thanks to a mirror between different linux > > distribution supported by yocto. > > If we build a sstate-cache on a debian 10 x86_64 buildfarm, and after that > > we use it on an ubuntu 18.04 x86_64, runqemu don't find several libs. > > We have reproduced this problem on two different pc with ubuntu 18.04 and > > 16.04. > > We don't have this problem, if we use the shared sstate-cache on another > > debian. > > In all cases, a ldd on the qemu binary shows us the use of local/host libs, > > not the yocto libs. > > Is it an expected behavior? or not? > > Runqemu's libs have to come from the linux distribution or from the yocto > > build env? > > There are two cases, depending on whether you have uninative enabled > or not. It's disabled by default in oe-core but enabled by default in > poky (the distro aimed at testing). > > With uninative disabled, native binaries link with host libc. Other > link dependencies are either native packages provided by OE or they > come from the host. In this case, sstate for native packages is stored > within a host specific subdirectory of sstate-cache (e.g. > sstate-cache/ubuntu-18.04). It should be quite safe to share > sstate-cache between different hosts (since different hosts should > each use a different subdirectory of sstate-cache). The downside is > that because different hosts don't share sstate, build times may be > slower. > > With uninative enabled, native binaries link with uninative libc. > Other link dependencies should only be native packages provided by OE > (ie they should NOT come directly from the host). In this case, sstate > for native packages is stored within a common subdirectory of > sstate-cache (ie sstate-cache/universal). The assumption is that > because native packages never link with libs from the host, sstate for > native packages no longer needs to be host specific. > > Unfortunately problems happen if uninative is enabled but a link > dependency is found from the host. That causes host dependent sstate > files to pollute sstate-cache/universal, making it unsafe to reuse > between different hosts. This doesn't happen often, but it does happen > sometimes, e.g: > > https://git.openembedded.org/openembedded-core/commit/?id=4a996574464028bd5d57b90920d0887d1a81e9e9 > > It looks like maybe it's happened in your case too. If you want to > share sstate-cache between different hosts the safest way is to > disable uninative. If you are happy to test and debug uninative then > of course give it a try, but be aware that it's not bug free.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138840): https://lists.openembedded.org/g/openembedded-core/message/138840 Mute This Topic: https://lists.openembedded.org/mt/74498490/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
