DEV Community

loading...

Discussion on: gRPC on dotnet core 3.1 on RaspberryPi 3

Collapse
erikest profile image
erikest Author

Ya, so my quick take here is that you're trying to do the compilation on the docker/pi4. I believe that grpc.tools and specifically that protoc is a compile time dependency.

In my post, I'm compiling for a specific runtime, but I'm doing it from a dev machine that is x64. Then I'm pushing those binaries over to the pi. My guess is that the compile time tools for x64 are being used to produce the protoc files at that point, so no proc arch mismatch. If you follow that workflow, you'll probably be fine. I'm not sure if you have a special use case for compiling on the pi directly, but it's probably faster to develop on a beefier machine and then just have script to push the binaries, which could be setup as a post build script, so the pi is always in sync. I have some (probably terrible) example scripts on the github project to do this.

Otherwise, you're right, linux_x86 native libs aren't going to do you any good on an arm processor - runtime or compile time. What would be needed there is essentially this same post, but pivoted to compile the protoc for arm32 and arm64. However, I would carefully consider the value of compilation on the pi - it's slow and you likely have a better dev machine already set up. That issue you linked to pretty clearly states the gRPC teams position on supporting arm, in short paraphrase, "we can't maintain the tooling and test environments, so you're on your own".

There is one 'meta' issue, which is that it's selecting a binary named ...x86.. even though it's on an arm processor. Someday, I'll post a PR to the grpc team that at least fixes this so that if community creates and maintains the arm versions of these libs, the code that selects them will at least be looking for the correctly named file in the correct location, instead of the hack we have now where I just named the arm file for x86.