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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.