On Sun, Oct 27, 2019 at 4:06 PM akuster808 <akuster...@gmail.com> wrote: > > > > On 10/27/19 4:03 AM, Alexander Kanavin wrote: > > On Sun, 27 Oct 2019 at 09:13, akuster808 <akuster...@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). >
https://lists.x.org/archives/xorg-announce/2019-April/002992.html does have header fixes which might be interesting to this issue > Alex > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
