On Tue, Nov 12, 2019 at 10:07 AM Alistair Francis <alistai...@gmail.com> wrote: > > On Tue, Nov 12, 2019 at 8:19 AM Khem Raj <raj.k...@gmail.com> wrote: > > > > On Sat, Nov 9, 2019 at 7:36 AM Alexander Kanavin <alex.kana...@gmail.com> > > wrote: > > > > > > On Sat, 9 Nov 2019 at 00:02, Alistair Francis <alistai...@gmail.com> > > > wrote: > > >> > > >> > right this means glx-tls is not working anymore, and it will fail on > > >> > musl at runtime > > >> > see > > >> > https://gitlab.freedesktop.org/mesa/mesa/issues/966 > > >> > > >> So what do we do here? > > >> > > >> There are some patches in that issue, but they don't cleanly apply and > > >> seem hacky anyway. Can we have two versions of mesa? One for musl and > > >> one for others until this is fixed upstream? > > > > > > > > > Maybe we can silence the warning for musl only, via > > > INSANE_SKIP_..._libc-musl = "textrel"? > > > ffmpeg does the same already. > > > > in this case, texrel will endup causing sigsegv, this is a mesa issue, > > primarily we have been working it around so far. > > I sent a new patch, it probably doesn't fix this issue though. >
sure, and I think we should be able to address it with a patch or some feature disable/enable a mechanism I wonder what changed in new build system that it cant be knobbed out as it used to be with autotools > We can't just not update mesa because of this. We can certainly take time to fix it, we are early in release cycle. What about having two > versions, or for musl and one for glibc? > Probably a bad idea > Alistair > > > > > > > > > Alex -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
