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 google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

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

diff --git a/recipes-devtools/protobuf/protobuf_%.bbappend b/recipes-devtools/protobuf/protobuf_%.bbappend
new file mode 100644
index 0000000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
--
2.17.1

I had to clean these up a little bit and pushed them to master-next. Please verify that they still work for you and if not used them as a starting point and send a V4 patchset.

On 8/17/2021 7:01 PM, Joshua Watt wrote:

I had to clean these up a little bit and pushed them to master-next.
Please verify that they still work for you and if not used them as a
starting point and send a V4 patchset.

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 static linkage for the
target build that we have not seen any issues with.

I'd like to keep target builds same supporting both static and dynamic
build but limit the tools to static link by using sdkmingw32 instead of
mingw32.

Should I send a V4?

On 8/17/21 11:29 AM, Sinan Kaya wrote:

On 8/17/2021 7:01 PM, Joshua Watt wrote:

I had to clean these up a little bit and pushed them to master-next.
Please verify that they still work for you and if not used them as a
starting point and send a V4 patchset.

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 static linkage for the
target build that we have not seen any issues with.

Are you building with "mingw32" as the target (not as the SDK), and it works there? I wonder why it only fails for the SDK build and not the target build? If that is truly the case, then yes I suppose it should be the "sdkmingw32" override. The strange thing about that (and why I thought it was incorrect) is that we have a few recipes that disable shared libraries and/or enable static with just the "mingw32" override, which is why I assumed it was a general limitation of MinGW, not just the SDK. I looked through the recipes, and it does seem more apparent that it is inconsistent, with a few recipe using "mingw32", a few using "class-nativesdk:mingw32", and a few using "sdkmingw32".


Anyway, please send a V4 if it needs to be changed, and I apologize for changing it unnecessarily :)

I'd like to keep target builds same supporting both static and dynamic
build but limit the tools to static link by using sdkmingw32 instead of
mingw32.

Should I send a V4?

On 8/17/2021 9:10 PM, Joshua Watt wrote:

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.

Are you building with "mingw32" as the target (not as the SDK), and it
works there? I wonder why it only fails for the SDK build and not the
target build? If that is truly the case, then yes I suppose it should be
the "sdkmingw32" override. The strange thing about that (and why I
thought it was incorrect) is that we have a few recipes that disable
shared libraries and/or enable static with just the "mingw32" override,
which is why I assumed it was a general limitation of MinGW, not just
the SDK. I looked through the recipes, and it does seem more apparent
that it is inconsistent, with a few recipe using "mingw32", a few using
"class-nativesdk:mingw32", and a few using "sdkmingw32".

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 nativesdk problem for grpc and protobuf is a silent failure. Even
though we are able to build the binary, we get a binary that just
doesn't work on windows. (crashes upon execution)

I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.

Anyway, please send a V4 if it needs to be changed, and I apologize for
changing it unnecessarily :)

Will do.

On 8/17/21 1:15 PM, Sinan Kaya wrote:

On 8/17/2021 9:10 PM, Joshua Watt wrote:

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.

Are you building with "mingw32" as the target (not as the SDK), and it
works there? I wonder why it only fails for the SDK build and not the
target build? If that is truly the case, then yes I suppose it should be
the "sdkmingw32" override. The strange thing about that (and why I
thought it was incorrect) is that we have a few recipes that disable
shared libraries and/or enable static with just the "mingw32" override,
which is why I assumed it was a general limitation of MinGW, not just
the SDK. I looked through the recipes, and it does seem more apparent
that it is inconsistent, with a few recipe using "mingw32", a few using
"class-nativesdk:mingw32", and a few using "sdkmingw32".

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 nativesdk problem for grpc and protobuf is a silent failure. Even
though we are able to build the binary, we get a binary that just
doesn't work on windows. (crashes upon execution)

I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.

RIght, the "mingw32" override shouldn't affect what you do with the *target* unless your target is MinGW; I'm not sure if anyone is actually doing that, most SDKs target Linux for ARM, Linux for AArch64, Linux for x86, etc.

What is your target?

It's important to remember that the recipe can be built differently for the SDK vs the target :)

Anyway, please send a V4 if it needs to be changed, and I apologize for
changing it unnecessarily :)

Will do.

On 8/17/2021 9:19 PM, Joshua Watt wrote:

I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.

RIght, the "mingw32" override shouldn't affect what you do with the
*target* unless your target is MinGW; I'm not sure if anyone is actually
doing that, most SDKs target Linux for ARM, Linux for AArch64, Linux for
x86, etc.

What is your target?

It's important to remember that the recipe can be built differently for
the SDK vs the target :)

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