On 8/17/2021 9:10 PM, Joshua Watt wrote:
We have use cases of both dynamic and static linkage for theAre you building with "mingw32" as the target (not as the SDK), and it
target build that we have not seen any issues with.
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 :)