gRPC on dotnet core 3.1 on RaspberryPi 3 (originally written for preview3, the nuget packages have been updated for the latest version)
t...
For further actions, you may consider blocking this person and/or reporting abuse
Thank You So Much For This ! It allowed me to work around a show stopped for running my twitch bot on a pi - but it calls out the Anki Vector Robot (to allow chat to make him talk), Vector uses gRPC under the hood and it wouldn't run on the pi, until I found your post and compiled and it worked :D Thank You !!!!!
Woo hoo! So stoked you were unstucked! When you get it all working, you could do a sweet post about how to make this robot work as a twitch bot on a pi :)
Could I be a little cheeky and ask if you could update the Nuget Package to the latest version (I'm not sure how to do)? - Thanks
I've been meaning to update it to the latest version, compiled against the latest version of .net core 3... Should be able to turn my attention to it in the next day or so :)
An updated version of the package compiled against the v1.26 branch of the grpc repo is live. Be warned, while testing against the latest sdk using the
dotnet publishcommand, it incorrectly chose the .so file from the grpc core package, ignoring the runtime identifier - this wasn't the case before, so I've filed an issue on github: github.com/dotnet/sdk/issues/4195In the meantime, after publish, you may need to manually copy the correct version, or set it up as a post build action.
Hello Erik,
This is an awesome write up -- I came across your blog while trying to solve this very problem for a different platform and thinking that the issue would affect Raspberry pi's as well and someone, somewhere, might have solved it.
I have a request! Is it possible for you to build an ARM64 version of your package? I'm trying to do dotnet coding on an Android tablet with an Ubuntu userland (oh yeah) and surprisingly everything works but gRPC! Before I found your blog, I tried using the ARM64 Android .so and copying it over the x64.so but unfortunately that didn't work. I'm hoping an ARM64 build would be an quick task for you and would solve my problem.
Thanks!
I compiled it myself using the scripts and steps in your github project and it worked perfectly! In fact, I compiled it on my Android tablet.
I think perhaps the Android version would have worked but I didn't realize that dotnet overwrites the native libraries in your bin/Debug directory from the .nuget package store on every
dotnet run.Excellent! That's exactly what I was going to suggest.
And regarding the overwriting issue - that could be related to a bug, which I've filed a github issue for, which has to do with the tooling's selection process for the native library: github.com/dotnet/sdk/issues/4195.
I might have to check out these vector robots as you're the author of the .net sdk and another Wayne who commented earlier, was trying to control said Vector robot from a Pi, presumably using your sdk :)
I was so excited to deploy my first gRPC .NET 5 project to my Raspberry Pi 4...only to see errors in my GitHub Actions when it tried to build my container. Searching the interwebs led me to this post which seems so tantalizingly close but IIUC your nuget package works for linux-arm (rpi3), not linux-arm64v8 (rpi4). I'm running the 64-bit version of Raspberry Pi OS and I'm stymied. :-( I'm trying to leave the box itself as untouched as possible and put all my dependencies in my Docker images so I'm not sure about building my own version of libgrpc_csharp_ext. Do you know of a resource or a way I could find a way to do gRPC with .NET 5 on arm64v8?
Hi,
Thank you very much for your research and nuget package.
I saw that you posted about regression issue that your nuget package does not override the file. But want to clarify is it related to issue that I have.
Basically I see the same bahavior as in this ticket github.com/grpc/grpc/issues/23336
I'm trying to build in the docker on raspberry pi 4 and getting:
/root/.nuget/packages/grpc.tools/2.29.0/build/_protobuf/Google.Protobuf.Tools.targets(264,5): error MSB6003: The specified task executable "/root/.nuget/packages/grpc.tools/2.29.0/tools/linux_x86/protoc" could not be run. System.ComponentModel.Win32Exception (8): Exec format error
As I understant it's because linux_x86/protoc is not built for arm. And libgrpc_csharp_ext.x86.so would not help much ? I'm a bit confused, sorry. I assume that grpc team have changed their approach in building stubs ?
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.
Hello all, I am trying to run gRPC on raspberry pi 4 with NET5.0 but I am receiving an error from GetArchitectureString method: "Unsupported architecture" . RuntimeInformation.ProcessArchitecture returns "ARM" what seems to be not supported. Do you have any idea whether it is possible to run it on rpi4 ?
I am using raspberry pi 4 with 32OS. When I used the same on raspberry pi3 then this problem was not existing.
Note also there are RPi with ARMv6. You won't be able to compile it with a stock compiler so more work needed here. Also I believe you can also allow linux-arm64 RID because armv7 is compatible with v8.
Hi @erikest ,
I am trying to run grpc core in a container with a built native .so library but I am getting this error:
dotnet: symbol lookup error: /app/libgrpc_csharp_ext.x86.so: undefined symbol: __atomic_fetch_add_8
Have you ever encountered this issue?
Thanks,
Pawel
I have not encountered that one specifically, no. Not sure what guidance to give you at this point as I would need a lot more context to understand.
Very helpful post! I can't describe how much I've struggled with libgrpc_csharp_ext.x86, thank you for all you effort! github repo with steps for building the library saved my day :)
It brings me such joy to hear from someone who benefited from this :) May you find great success in your gRPC pi project!
That's amazing! Thanks for making this!
I really hoped while getting through this post that someone would find the work and get to carry on blissfully with their awesome open source .net core pi project and poking into your github repo and seeing the package reference there made me very happy :) Good luck with NucuCar (github.com/dnutiu/NucuCar), looks like a fun project!