03:00 <smurray> khem: almost seems Fedora et al might have hit that with perl in their switch to enabling v2/v3 versions of things?

03:00 <khem> seems not

03:01 <khem> some more digging reveals that if I use -fno-builtin-memcpy then things work

03:01 <khem> that atleast explains why it works with clang and not with gcc

03:02 <khem> memcpy intrinsic assumes certain things especially around alignments

03:03 <khem> when we enable SSE4.2 and AVX

03:05 <khem> gcc's intrinsic for __builtin_memcpy assumes non-overlapping regions and is vectorized

03:06 <smurray> I'm kind of surprised that perl has issues like this these days with all the platforms it's been ported to

03:10 <khem> oh it has many things like questionable pointer punning.

03:10 <khem> thats why -fno-strict-aliasing is needed

08:05 <walter> I have a question, is there a place that mentiones that you need to clean a recipe after you make some changes? I've missed such a thing in the docs, but it seems to be required. For example, I've added `PACKAGECONFIG:pn-xserver-xorg:append = " udev glx"`, then I had to clean it before rebuilding. I feel like this is something that is given after you know yocto, but a gotcha when you get started.

08:06 <walter> Also, party time!!! I've managed to build yocto for my board. I'm not sure if it works, I'll get the SBC next week, but yocto is building, so that's progress!

08:20 <walter> Question, where does this DTB come from? /build/tmp/deploy/images/rock-pi-4b/rk3399-rock-pi-4b.dtb -- Is it generated for the kernel source code? The thing is I need a different DTS from there, one with an extra "-plus" in the name. Do I need to provide my own machine for this?

08:32 <walter> So, I've managed to add an extra machine file to the meta-rockchip layer and it seems to work, but I don't know how to deal with the uboot defconfig, do I need to clone uboot locally and use it somehow? or how do I provide an alternative defconfig for it, I saw that the uboot defconfig contains a reference to the DTS, which needs to be changed.

17:06 <khem> walter: I suggest to use git for recording your local changes, its quite powerful that way. You can then revise all local changes you did on top of known base

17:07 <khem> DTB is usually built as part of kernel or maybe bootloader in some machine types

17:10 <khem> Generally KERNEL_DEVICETREE variable defined in machine conf file dicatates what it will be for that machine, you can however change it either in the machine conf or via some other config metadata change like in local.conf or some such if you dont want to change the machine config from BSP layer

17:56 <walter> I ended up creating a new layer and moved local.conf changes to there, I then moved everything outside of poky, because the default poky tutorial makes you work in a build directory inside the poky source code. I didn't bother with git, since I still don't know what I'm doing, so a simple backup of the conf file worked until now.

17:57 <walter> Question, are UBoot device trees the same as those from the kernel? Or are they usually different? I'm thinking of sending patches when I get to test the build onto a real board.

18:00 <walter> (The kernel has dts files for my board, but not UBoot)

18:15 <fray> u-boot device trees in my experience are implementation specific. With that said, where I work, we've decided to recommend to customers that they use the same deviec tree for Linux and u-boot.. but you can absolutely have different ones

18:26 <walter> I see, thanks!

19:58 <RP> khem: perhaps we just skip that test?

20:35 <RP> khem: ah, I see a patch, thanks