I was hoping for free cycles. I didn't get one. This will be an intern project. The way I'm thinking is to have the ABI compat XML be part of the state cache tgz file and come up with a CVE check kind

That's true, this will require engagement from the community. Tool could take few iterations to perfect. Until then, I expect tool owner to be responsible for fixing these bugs. Once stability is reac

What would be the minimum acceptable solution with the least investment? in other words, do we have a list of requirements? Our team has posted a solution. BMW folks posted a solution. None of them go

My research says libnsl is a soft requirement for c-ares. GRPC assumes libnsl to be present and used by default. However, it will build without it too. https://www.linuxfromscratch.org/blfs/view/svn/b

There is a new PACKAGECONFIG for grpc to allows us to selectively enable/disable shared builds. Signed-off-by: Sinan Kaya <okaya@...> --- .../openembedded-layers/recipes-devtools/grpc/grpc_%.bb

Patch sent with subject: [meta-oe][PATCH] grpc: make SHARED library build optional I will wait until it gets merged to follow up here.

Signed-off-by: Sinan Kaya <okaya@...> --- .../openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dynamic-layers/openembedded-layers/r

Signed-off-by: Sinan Kaya <okaya@...> --- .../recipes-support/c-ares/c-ares_%.bbappend | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 dynamic-layers/openembedded-layers/recipes-suppo

Signed-off-by: Sinan Kaya <okaya@...> --- .../openembedded-layers/recipes-support/re2/re2_%.bbappend | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 dynamic-layers/openembedded-layers

ah, mine is both arm and arm64. No need to touch the recipe then.

I see two classes of problems based on my engagement with the mingw32. Some recipes just don't build without using the static method for the SDK and the target both. (abseil-cpp is one of them) The na

Sounds good. What do you think about this? My reading of the problem says that the problem only happens on win32 platforms due to how DLLs initialize the heap. We have use cases of both dynamic and st

Add a dynamic BBFILES pattern so that patches for openembedded-layer are conditionally applied only if meta-oe is present. Signed-off-by: Sinan Kaya <okaya@...> --- conf/layer.conf | 9 ++++++++

Signed-off-by: Sinan Kaya <okaya@...> --- recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend | 1 + 1 file changed, 1 insertion(+) create mode 100644 recipes-devtools/abseil-cpp/abseil-cpp_%.bbap

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641] File already exists in database: google/protobuf/descriptor.proto [libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed: Ge

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641] File already exists in database: google/protobuf/descriptor.proto [libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed: Ge

Dynamically linked protoc.exe is failing as follows: [libprotobuf ERROR google/protobuf/descriptor_database.cc:641] File already exists in database: google/protobuf/descriptor.proto [libprotobuf FATAL

My reading of the problem says that the problem only happens on win32 platforms due to how DLLs initialize the heap. We have use cases of both dynamic and static linkage for the target build that we h

I wasn't aware of this functionality. Will post v3.

Signed-off-by: Sinan Kaya <okaya@...> --- recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend | 1 + 1 file changed, 1 insertion(+) create mode 100644 recipes-devtools/abseil-cpp/abseil-cpp_%.bbap