[OE-core] State of stable warrior in Core/bitbake/YP layers

akuster808 akuster808 at gmail.com
Sun Oct 27 15:05:59 UTC 2019



On 10/27/19 4:03 AM, Alexander Kanavin wrote:
> On Sun, 27 Oct 2019 at 09:13, akuster808 <akuster808 at gmail.com
> <mailto:akuster808 at gmail.com>> wrote:
>
>     Of the past month the warrior stable branch has been plagued with a
>     build failure on FedoraCore30 regarding qemu virgl tests. This has
>     caused the slip of the next dot release to occur after Thud's.
>
>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=13543
>
>     The error message was this:
>
>     runqemu - ERROR - Failed to run qemu: libEGL warning: MESA-LOADER:
>     failed to open swrast (search paths /usr/lib64/dri)
>     libEGL warning: MESA-LOADER: failed to open swrast (search paths
>     /usr/lib64/dri)
>
>     qemu-system-i386: egl: eglInitialize failed
>     qemu-system-i386: OpenGL is not supported by the display
>
>     What has fixed this error is updating libdrm to 2.4.99 from
>     2.4.97. What
>     I can not tell is what commit(s) in those updates fixed the above
>     error
>
>     https://lists.freedesktop.org/archives/dri-devel/2019-July/225069.html
>     https://lists.x.org/archives/xorg-announce/2019-April/002992.html
>
>     Has anyone seen the above error and might have an idea what commits
>     would solve this issue?
>
>
> The DRI modules loaded from the host (swrast particularly) may try to
> resolve a symbol in libdrm-native that doesn't exist.

What I justed noticed on the host is that his has both 5.2 and 5.3
kernels. FC 30 was tested in the 2.7.1 so it worked at one point in
time. I wonder if the kernel got updated to 5.3 and now we need updated
headers for libdrm? That might support the missing symbols you mentioned
above.

Thanks for the hint.

- Armin
>
> I remember debugging a similar problem when TLS got accidentally
> switched off in mesa-native, what helped was tracing symbol
> resolution with the help of environment variables described in 'man
> ld.so' (can't remember off the top of my head what was the exact one).
>
> Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191027/02b71bcb/attachment.html>


More information about the Openembedded-core mailing list