But this is exactly what happens: the kernel reads the dynamic loader/interpreter path from the binary (which is different than the list of dynamically linked libraries printed by ldd), isn't able to

I used the x86_64 variant from the layer (it only downloads the binaries and copies them). And I checked that with ldd, it seemed ok so

That layer does have the x86_64 variant as well, no? Is it not working? https://github.com/RDunkley/meta-dotnet-core/blob/master/recipes-runtime/dotnet-core/dotnet-core_3.1.1.inc The error you're

Hello Alex, Thanks for replying. Yes, I know that this isn’t the way it works on Yocto (and I told the managers it is a crappy idea to do that more than once). But they need .NET Core in that

Yocto generally does not support this use case. The binary was compiled in a different environment and expects things in different places, and probably being different versions too. I could point out

Hello, I’m trying to create a normal QEmu (x86-64) Image, which I can let run in Virtualbox. As a addition I deployed .NET Core, which I got from this

A build flagged for QA (yocto-3.0.2.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.0.2.rc2 Build hash information: bitbake:

Yocto is a community project. If you think such a tool is missing, patches are welcome. Talk to your employer about ability to contribute under your real name. Alex

Post/* all ( except Post/migrations/* , __init__.py and templatetags/* ) have some sort of MIT headers; adding SPDX header to make it obvious. project/* & test-data/* all ( except __init__.py ) have

Images are supposed to be all custom. It means if you cannot easily use one of the existing images, you create your own. There are ways to bbappend an existing image and mangle its content, but it's

was able to modify the vendor's machine/inc file to remove the offending package. Since the whole tree is in git now, I suppose that's OK, but I do wish yocto had better tools for managing inclusions

On 2/11/20 11:16 AM, rpjday@... wrote: Wrong ML. We have a docs@... with patchwork support. - armin

Minor fixes: - punctuation - capitalization - markup - wording Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git

You need to modify the image recipe so that those packagegroups are not pulled in. If you cannot do that because it's in a layer controlled by someone else etc, then make a new image recipe, and build

My vendor finally realized that I needed a full yocto release and not the eSDK. Anyway, I can build their image, but when I modify the kernel to remove CAN drivers I get the errors

From: Sergey 'Jin' Bostandzhyan <jin@...> Currently machine configs define the partition layout for each machine by setting the WKS_FILE variable. However, there are situations where it may

From: Sergey 'Jin' Bostandzhyan <jin@...> Currently machine configs define the partition layout for each machine by setting the WKS_FILE variable. However, there are situations where it may

Current Dev Position: YP 3.1 M3 Next Deadline: YP 3.1 M3 build date 2/24/2020 Next Team Meetings: Bug Triage meeting Thursday Feb. 13th at 7:30am PDT (https://zoom.us/j/454367603) Monthly

from the overview manual, section 2.5, "Reference Embedded Distribution (Poky)", there is the note: "While Poky is a "complete" distribution specification and is tested and put through QA, you cannot

Ah gotcha. My docbook-fu is somewhat hazy. Yes, seems sensible. Ross