Please find out which layer is adding this bbappend you could use bitbake-layers show-appends sysvinit It seems recipe version is newer perhaps and the bbappend is still made for older recipe, these t

#dunfell

it will depend on release, if you are on 3.0+ then yes single setting will work, older releases would mean above is needed. see https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=in

#dunfell

there is similar segv I see on master, Can you test this patch on master and see if that works? secondly, also try master branch of weston and see if it fixed it then we can narrow down needed backpor

see http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.3.bb?h=dunfell#n114 change that to -Dfdkaac=enabled if it works, then perhaps tu

#yocto

this is upto your component's build system, so perhaps you should look into that and ensure that its using right options. Second place to look is recipe for your package and ensure right vars and opti

<Jasper.Orschulko@...> wrote: I see, this is a workaround that will work in this case but may not work in case where the PN is not empty but static linking it happening. So I think in cas

<Jasper.Orschulko@...> wrote: I am not sure why you will include empty packages in your manifest

<nicolas.dechesne@...> wrote: perhaps good time to consider matrix

usually it means lua version mismatch. You might be hitting same issue as reported here https://trac.videolan.org/vlc/ticket/25036 there is a patch attached to that ticket. Please try to apply that an

partly yes. there is a provision to disable static linking using DISABLE_STATIC, so atleast some of packages can be cleared of. depends are effective during build time and its the linking which decide

yes. Please send this change as a proper patch for inclusion to openembedded-core mailing list. > > > >

#dunfell

I can think of few ways build your Xtensa firmware outside yocto and let yocto package it via recipes for prebuilts and build ARM system with yocto should work well second option is to integrate Xtens

Can you create a pull request on github for this please.

Hello Jack, I think we do not have support for Xtensa architecture working out of box upstream. Although it should be possible to add it with little effort, but no one has spun patches to do so thus f

did you look into http://layers.openembedded.org/layerindex/recipe/135534/

#yocto #zeus #python

Signed-off-by: Khem Raj <raj.khem@...> Cc: Ross Burton <ross.burton@...> --- .../files/0001-Fix-build-with-gcc-11.patch | 34 ++++++++++++++++++ .../0001-dram-Fix-build-with-gcc-11.patch | 34

right, that's what if we want to do this then it has to be persisted with otherwise it will end up being one time exercise with all these losses you described.

I think it is a good idea, however, to make it persistent it would be nice to have a linter, which can do such checks and perhaps we can enable this in autobuilders so we can keep such cleansups maint

usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missin

#yocto

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

#yocto