-
Notifications
You must be signed in to change notification settings - Fork 651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
missing pre-compiled arm binary #1405
Comments
This is also an issue when running inside Docker on the new MacBook with the M1 Chip. |
Given the introduction of Apple Silicon, and the fact that Docker for Mac on these machines use arm64, does it make sense to re-open this case? Building JS apps that depend on grpc (directly or indirectly) is no longer possible in Docker on Mac (or at least not easy; e.g I can't make the |
@remko is right, I'd reopen this one. Some issues I came across with just can't be sorted out that easily. |
Our build process runs on GitHub Actions, so adding this is blocked on actions/runner-images#2187. |
Can anyone share the instructions on how to build the binaries from the source code? |
Basically https://github.com/grpc/grpc-node/blob/master/packages/grpc-tools/build_binaries.sh This script probably requires changes, but we have no way of testing on any M1 hardware, so you'd be on your own to change it. |
@nicolasnoble @murgatroid99 I am actually using trying to install the grpc-tools on AWS Graviton 2 instances. Are there any instructions on how to run the test cases? I have access to both M1 hardware and Graviton instances. I can run the test cases and share my findings/results. |
For any on M1 hardware running into this, I was able to workaround it by just forcing the x64 binary and letting Rosetta deal with it: yarn add grpc-tools --ignore-scripts
pushd node_modules/grpc-tools
node_modules/.bin/node-pre-gyp install --target_arch=x64
popd Is there any way to include this during normal install? |
I think you can pass the |
@shnhrrsn Also, if you use nvm, you can install x86 node versions following the steps under the "Macs with M1 chip" section of https://github.com/nvm-sh/nvm#macos-troubleshooting. This one solved all my M1 related issues. |
ARM binaries should be distributed as part of releases. Especially in 2021. Many cloud providers and personal computer manufacturers are beginning to implement ARM as larger offerings. This is also troublesome for raspberry pi users who would like to run node apps. There isn't a good reason not to pre-compile these binaries, otherwise node marketshare will lessen. I'm already pretty frustrated with it and will be doing less node development as a result. |
@murgatroid99 |
I said that making this change is blocked in #1405 (comment). Nothing in the linked issue appears to have changed, so it's still blocked. |
lol that issue is blocking SO many people |
Apple Silicon is here to stay and so is grpc-node. Please reconsider :) |
That comment predates the announcement of Apple Silicon. I wasn't talking about Apple Silicon. As I said in my more recent comments #1405 (comment) and #1405 (comment)
|
I'm curious why there's not a fallback setting to just compile the binaries if no prebuilt exists. Other packages do something similar. Edit: it appears node-pre-gyp is being abused to just download files. because we're not actually using a binding to node for those tools? |
I disagree with the term "abused". We are using node-pre-gyp to do what it is supposed to do: download binary files for the system the code is running on. It doesn't have a fallback to building locally because it is building protoc, which has an existing build process that uses cmake instead of node-gyp. |
Abused might be a strong word, but it's certainly a tad misused. Their docs say it should "stand between" npm and node-gyp. If we can't fallback using the node-gyp to build, i wonder if there's a good way to wrap node-pre-gyp to just auto run ./build_binaries.sh if that fails? Here's how i got around this without using Rosetta:
|
Think of it more as a stop gap, really. The reality being that building protoc from pure source is impossible due to its bootstrapping nature, and so we can't write a node-gyp installer for it, which requires a very flat list of files to compile, with no intermediate compilation process. Ideally, node-gyp should support cmake, but that's also not happening: nodejs/node-gyp#1590 Additionally, Apple has made it very difficult to build software on their new M1 hardware when using things like github actions, rendering us basically powerless to create working M1 binaries. So we're stuck between a rock and a hard place here, and there's no good solution unfortunately. |
Did anyone find a fix when running in Docker? We have a team that develops in VSCode Remote Containers (ie. docker containers) - some have M1 chips others intel. Any way to support both? |
@antonimmo That doesn't work when inside a debian-bullseye docker container (on a Mac M1 host) since |
Looks like we must build grpc-tools ourselves for Apple Silicon? |
@murgatroid99 I updated to that new version and it worked a treat. Thank you! |
Updated too and works great now without any work arounds. Thank you! 🙏 |
Still missing linux arm64 binary 😢
|
Still not available for linux (exp: if you have a docker image):
so I've added the following to my dockerfile
|
@source-transformer Excuse me, but how does this work? Assuming you have an arm64 Linux image, how is it able to run x64 binaries? Wouldn't that result in an error anyway? Or do you just install the package but not actually use its components which require x64 binaries? |
Correct - I should have qualified my answer with - you can't actually run grpc-tools on your container. I had tried the following:
In the hopes of getting a binary that potentially could be run. But, honestly that was just a shot in the dark as to the correct label/alias for the 32 bit build/architecture. I wasn't sure how to get a listing of supported architectures. In my case - it isn't necessary to actually run grpc-tools on my docker container - since those tools are "devDependencies" and their output is actually copied to the docker image. |
Will it support linux arm64 in the future? I'm looking forward to it. |
A while back we made an alternative mirror for this... |
How to bulid linux arm64? when I follow with this document: https://github.com/grpc/grpc-node/blob/master/packages/grpc-tools/build_binaries.sh。Error occurred:
ldconfig -p | less
|
I'll have to look again, it's been a while. I know it was pretty simple, though. |
2 years later this issue still open
|
@murgatroid99 and other contributors, are you planning to add support for the arm architecture? if you don't have enough time for that, I'd like to try to add arm support to your library. |
I have no immediate plans to add this myself. If someone contributes a build change that produces ARM binaries for grpc-tools, I will accept it and publish them. |
As soon as I remember how I did it, I'll integrate it into the build system and make a PR. (I hope that this message showing up multiple times is just a glitch in the GitHub app on my phone.) |
@murgatroid99 I just finished a patch. https://github.com/RedstoneWizard08/grpc-node PR: #2333 |
Merged! |
The Linux ARM64 binary is now available in version 1.12.4. |
actually it hasn't: #2378 |
Is it planned to support M2 architecture as well? |
Which repo are we talking about here? It sounds like folks have gotten grpc-node to work on Mac M series, is there a concise set of instructions I can follow? |
Problem description
Can't install grpc-tools on arm architecture (raspberry pi) because of missing precompiled binaries.
Is it possible to build these at all?
Reproduction steps
npm init
npm install grpc-tools
Environment
Additional context
The text was updated successfully, but these errors were encountered: