You can specify a directory relative to the one the recipe is in in SRC_URI. Bitbake will checksum all files in it (so will trigger a re-build if they change), and will copy the directory into the $WO

#yocto

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

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 seei

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

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

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

The DISTRO_VERSION in your log is not 2.7 or 3.0, it is 1.8, which is ancient and won't build on current Debian. How did you set up the source tree? Alex

Ping :) Alex

Why separate them? I’d rather have newbies and experts in the same room. Alex

The idea is that when a recipe build completes, you get not just the packages from that recipe, but also all packages that are in its recursive dependencies. So that you can install any package from y

If the tool is executed with a direct path in a script e.g. #!/usr/bin/python or the host path is hardcoded inside a binary, there's nothing you can do (other than temporarily rename python to somethi

It would be really wrong to for the exact same source tree (of your plugin) to get assigned different versions depending on something else entirely. The version comes from the source tree of the compo

Just a quick thing for you to try: can you delete /usr/bin/monodis from your host and retry building? (remember to clean sstate for your package) Alex

I assume you want to upgrade because openssl 1.0 is no longer supported upstream, and you want to keep your stack secure, is that so? What is the reason behind it? What I am getting at is that updatin

Thanks Paul, maintenance work is always greatly appreciated. Alex

There are ways to adapt such a proprietary layer. If the intranet location is set with a bitbake variable, then you can adjust the variable to point to *your* intranet, and mirror all the needed piece

To me it seems that the SDK is the wrong kind of delivery to begin with (as it is basically a frozen target image configuration without the ability to customize the entire system build; Yocto SDKs are

I would like to add that it helps enormously if you introduce yourself to the community properly. When you do not state what your company is, who is your OEM, and write from a gmail account using what

This should be going to the oe-core list. Alex

Signed-off-by: Alexander Kanavin <alex.kanavin@...> --- .../0001-Fix-builds-with-gettext-0.20.patch | 38 +++++++++++++++++++ recipes-extended/sed/sed_4.1.2.bb | 4 +- 2 files changed, 41 insertio