Hi Jared Please see [1] usually sending to the right mailing list and CCing the maintainers is the usual way to send patches [1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-qt4/tree/README

This was enabling ssp support in glibc not only for other programs but also for rest of glibc components during compile and that resulted in duplicate symbols, IIRC thats why we disabled it, the error

seems fine. Please send a patch for enhancing it via docker.cfg

#meta-virtualization

you might want to use latest master, fix that you might find useful is https://git.openembedded.org/openembedded-core/commit/?id=7f577c10913104860121f682b9b3754870c4db23

So it seems your makefile is not respecting the LDFLAGS coming from the environment during linking. perhaps you should fix that in your linking rules. hardcoding hash style like this is not portable.

x86 is for 32 bit intel arch you won’t see It in pure 64bit machines

use of override here seems unnecessary > > > > >

yocto provides a layer to abstract native binaries on top of build host and thats what you are seeing. Its as designed. > > >

#toolchain #sdk #bitbake #native

look at meta-browser/meta-chromium as well.

I think its not a general problem with autotool based projects doing out of tree builds but just with sqlite3 package. Perhaps you might want to look at compiler commandline options being passed to sq

#dunfell

I think looking into buildhistory metadata might give some hints, it stores the information about image to package dependencies in a dotty file which you can either open in a viewer or text editor and

that should have worked well for userland recipe to provide it. Maybe you need to set VC4GRAPHICS = "" in local.conf <GWilson@...> wrote:

It should have automatically found user land package as one of providers but if it is not doing so that means it’s being ignored because it’s not compatible arch or something Are you compiling 32bit m

it should be provided by userland package if you are using closed source graphics driver.

can you check boot/config.txt and see fi your changes are there in your target ?

Libraries have another symlink which looks something like libfoo.so.1 and 2 etc that is the one which should be used by apps

unversioned symlinks should not be used they are there to be used for linking during build time. Unless you need to do builds on targets you really do not need them so explain you usecase. Are you try

perhaps use OnCalendar=*-*-* *:*:00

there are different possibilities you have with all great tooling you get with yocto project, I think you have made a good choice. inherently Yocto project is a cross compiling infrastructure so lot o

its hard to say what might be going on. Perhaps enable builds with V=1 so you can see if its always failing to compile at same file. or atleast you can get one file where it fails then you can use pre