From: Thomas Goodwin <btgoodwin@...> The preceeding errors that would be shown should be enough to identify the problem since it would have been a problem running bitbake-layers add-layer,

From: Marco Cavallini <m.cavallini@...> Signed-off-by: Marco Cavallini <m.cavallini@...> Signed-off-by: Richard Purdie <richard.purdie@...> --- config.json

Signed-off-by: Richard Purdie <richard.purdie@...> --- scripts/prepare-shared-repos | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/prepare-shared-repos

Signed-off-by: Richard Purdie <richard.purdie@...> --- scripts/prepare-shared-repos | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/prepare-shared-repos

Signed-off-by: Richard Purdie <richard.purdie@...> --- scripts/prepare-shared-repos | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

From: Thomas Goodwin <btgoodwin@...> The previous fixes requires the user to set "no-layer-add" for a repo and then use ADDLAYER to insert the sub-repos (e.g., meta-openmbedded/meta-oe) as a

From: Thomas Goodwin <btgoodwin@...> The return value from bitbakecmd was not being returned when errors occurred which allowed shared-repo-unpack to succeed despite the failure. This fix

Signed-off-by: Richard Purdie <richard.purdie@...> --- README | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README b/README index a6c4f1d..2747510 100644 --- a/README +++

We're not interested in these warnings, the license incompatibility is expected. By hiding these, we'll notice when warnings we do care about appear. Signed-off-by: Richard Purdie

This was copied from the old autobuilder configuration without much thought. It would only be effective if we had a common PRSERV or saved the database but we don't. It therefore makes sense to

fyi... I am using CMake with GNU, that is what is required for the build. I do source the SDK environment script prior to attempting build. Here is my current environment-setup-corei7-64-poky-linux

The simplest solution is to use autotools or Cmake for your project. That will automatically "do the right thing" to get the library properly installed and registered. Even if your project is just

i ran devtool modify dhcpcd and there is no "socket.c" in the source tree.

Perhaps you need to use ${CC} and ${CXX} etc. in your makefile, and also source the SDK environment script in shell, before using it.

Discern between source distributions and binary distributions. Yocto project provides tools to build either of those, but it does not support interoperability with other binary distros e.g.

Image builder uses debian naming for shared libs, and libraries are usually pulled in via shlibs resolver as a dependency so it would be good for you to ensure that this library has a use in image

Can you try adding #include <sys/param.h> into socket.c and see if that help ? if it does then please send it as a patch > > >> >> > > >

in library's build system you want to use symbol versioning during linker stage. Then you can create using ln cmd to creating symlink to lib.so and lib.so.<major_version> see [1] dev packages

Hey Paul, First of all, thank you so much for doing this. It's very much appreciated, I am very happy to see our community members willing to contribute to such a great internship program. As I

Looking to understand why the SDK is searching the host/native (x86_64-pokysdk-linux) side when it should be looking at the target side (corei7-64-poky-linux) … All the “crt” files are