missing pre-compiled arm binary
Closed this issue Β· 81 comments
Problem description
Can't install grpc-tools on arm architecture (raspberry pi) because of missing precompiled binaries.
node-pre-gyp ERR! stack Error: 404 status code downloading tarball https://node-precompiled-binaries.grpc.io/grpc-tools/v1.8.1/linux-arm64.tar.gz
Is it possible to build these at all?
Reproduction steps
npm init
npm install grpc-tools
Environment
- Ubuntu 20.04 arm64
- 10-12-14
- n
- grpc-tools, possibly more grpc packages - haven't checked yet
Additional context
error /home/repo/grpc/node_modules/grpc-tools: Command failed.
Exit code: 1
Command: node-pre-gyp install
Arguments:
Directory: /home/repo/grpc/node_modules/grpc-tools
Output:
node-pre-gyp info it worked if it ends with ok
node-pre-gyp info using node-pre-gyp@0.12.0
node-pre-gyp info using node@10.20.1 | linux | arm64
node-pre-gyp WARN Using request for node-pre-gyp https download
node-pre-gyp info check checked for "/home/repo/grpc/node_modules/grpc-tools/bin/grpc_tools.node" (not found)
node-pre-gyp http GET https://node-precompiled-binaries.grpc.io/grpc-tools/v1.8.1/linux-arm64.tar.gz
node-pre-gyp http 404 https://node-precompiled-binaries.grpc.io/grpc-tools/v1.8.1/linux-arm64.tar.gz
node-pre-gyp ERR! install error
node-pre-gyp ERR! stack Error: 404 status code downloading tarball https://node-precompiled-binaries.grpc.io/grpc-tools/v1.8.1/linux-arm64.tar.gz
node-pre-gyp ERR! stack at Request.<anonymous> (/home/repo/grpc/node_modules/node-pre-gyp/lib/install.js:149:27)
node-pre-gyp ERR! stack at Request.emit (events.js:203:15)
node-pre-gyp ERR! stack at Request.onRequestResponse (/home/repo/grpc/node_modules/request/request.js:1059:10)
node-pre-gyp ERR! stack at ClientRequest.emit (events.js:198:13)
node-pre-gyp ERR! stack at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:565:21)
node-pre-gyp ERR! stack at HTTPParser.parserOnHeadersComplete (_http_common.js:111:17)
node-pre-gyp ERR! stack at TLSSocket.socketOnData (_http_client.js:451:20)
node-pre-gyp ERR! stack at TLSSocket.emit (events.js:198:13)
node-pre-gyp ERR! stack at addChunk (_stream_readable.js:288:12)
node-pre-gyp ERR! stack at readableAddChunk (_stream_readable.js:269:11)
node-pre-gyp ERR! System Linux 5.4.0-1008-raspi
node-pre-gyp ERR! command "/usr/local/bin/node" "/home/repo/grpc/node_modules/grpc-tools/node_modules/.bin/node-pre-gyp" "install"
node-pre-gyp ERR! cwd /home/repo/grpc/node_modules/grpc-tools
node-pre-gyp ERR! node -v v10.20.1
node-pre-gyp ERR! node-pre-gyp -v v0.12.0
node-pre-gyp ERR! not ok
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 platform trick work with docker-compose, and there are many qemu crashes when running in emulated mode on an M1).
@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?
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
popdIs there any way to include this during normal install?
I think you can pass the --target_arch=x64 argument directly to npm install. I assume it works the same way with yarn, but I don't use yarn.
@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
Any chance this group can reconsider?
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.
Our build process runs on GitHub Actions, so adding this is blocked on actions/virtual-environments#2187.
lol that issue is blocking SO many people
We do not intend to distribute ARM binaries for
grpc-tools. I suggest generating your code on a different system and then transferring your code to your ARM system instead.
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)
Our build process runs on GitHub Actions, so adding this is blocked on actions/runner-images#2187.
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:
- clone this repo
- install your grpc-tools with
yarn install --ignore-scripts - run the script ./build_binaries.sh in the grpc-tools package
- copy your files over, something like this:
#!/bin/bash
cp binaries/arm64/protoc node_modules/grpc-tools/bin/protoc
cp binaries/arm64/grpc_node_plugin node_modules/grpc-tools/bin/grpc_node_plugin
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.
This is also an issue when running inside Docker on the new MacBook with the M1 Chip.
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?
@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.
@antonimmo That doesn't work when inside a debian-bullseye docker container (on a Mac M1 host) since arch -x86_64 zsh causes an error.
Looks like we must build grpc-tools ourselves for Apple Silicon?
I'm a beginner here. Could anybody kindly share a pointer to how to build it locally?
Looks like we must build grpc-tools ourselves for Apple Silicon? I'm a beginner here. Could anybody kindly share a pointer to how to build it locally?
Clone this repo, then cd grpc-node/packages/grpc-tools; git submodule update --init --recursive; ./build_binaries.sh should build the binaries. Make sure you have XCode/Command Line Tools installed.
@ldx Thanks a lot! I also found that I could resort to the emulated version with a Rosseta-enabled Terminal copy and install the Intel-edition Homebrew.
Kind of off-topic question for the workaround to work.
Is it possible to list the built binary in package.json as fallback when a binary is not available? My issue is that grpc-tools are listed as a dependency which works for all developers except those with M1.
@ldx Thanks a lot! I also found that I could resort to the emulated version with a Rosseta-enabled Terminal copy and install the Intel-edition Homebrew.
could you please give more details on how you did all of that?
Kind of off-topic question for the workaround to work.
Is it possible to list the built binary in package.json as fallback when a binary is not available? My issue is that
grpc-toolsare listed as a dependency which works for all developers except those with M1. For M1 I want to use the compileddarwin-x64.tar.gzinstead.
It is possible and would be nice to be able to build it if a precompiled binary is not available.
I am on an apple m1 chip.
My workaround.....
arch -x86_64 bash
touch ~/.bashrc
curl -sL https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.0/install.sh -o install_nvm.sh
# I wanted to use node 14, so I had to uninstall and reinstall with new arch
nvm uninstall 14
nvm install 14
# navigate to your project dir in the same terminal window running diff arch
cd ~/<my-project-dir>
rm -rf node_modules && rm package-lock.json
npm i
# run start command
npm startIf someone wants to do this in a less hackish way: build the binaries for ARM64, then create a tarball named darwin-arm64.tar.gz with these two files in it:
drwxr-xr-x root/root 0 2021-12-07 12:13 bin/
-rwxr-xr-x root/root 12023196 2021-12-07 12:13 bin/protoc
-rwxr-xr-x root/root 5945229 2021-12-07 12:13 bin/grpc_node_plugin
You can use an S3 bucket as a mirror, upload the tarball under the path grpc-tools/v1.11.2/darwin-arm64.tar.gz (match the version to whatever version of grpc-tools you use), make it public, and then npm install --grpc_tools_binary_host_mirror=https://<my-bucket>.s3.amazonaws.com/ should work. You might also want to mirror the tarballs for other platforms, e.g. https://node-precompiled-binaries.grpc.io/grpc-tools/v1.11.2/darwin-x64.tar.gz and https://node-precompiled-binaries.grpc.io/grpc-tools/v1.11.2/linux-x64.tar.gz if you also use x86-64 Mac OS or Linux.
Did anyone manage to install grpc-tools inside a vscode devcontainer on a M1 mac?
I can install grpc-tools by using the solution suggested by @davetisyan95 but I can't do that inside a docker container.
I'd also love to see a full example with the suggestion from @ldx - Basically I have grpc-tools as dependencies in package.json and I want to be able to run yarn install on a M1 and non-M1 machine (inside docker containers). I haven't figured out how to do that
Did anyone manage to install
grpc-toolsinside a vscode devcontainer on a M1 mac?I can install
grpc-toolsby using the solution suggested by @davetisyan95 but I can't do that inside a docker container.
Did you try what was mentioned here?
Did anyone manage to install
grpc-toolsinside a vscode devcontainer on a M1 mac?
I can installgrpc-toolsby using the solution suggested by @davetisyan95 but I can't do that inside a docker container.Did you try what was mentioned here?
Yeah I use docker compose up and then I get
Error response from daemon: image with reference node:16-bullseye was found but does not match the specified platform: wanted linux/amd64, actual: linux/arm64/v8
Actually I just realized that I should first delete the existing image with arm64 architecture - I'll report back
Update
It might solve it - now I'm just getting different errors and I can't say if this is related to this or not yet
If someone wants to do this in a less hackish way: build the binaries for ARM64, then create a tarball named
darwin-arm64.tar.gzwith these two files in it:drwxr-xr-x root/root 0 2021-12-07 12:13 bin/ -rwxr-xr-x root/root 12023196 2021-12-07 12:13 bin/protoc -rwxr-xr-x root/root 5945229 2021-12-07 12:13 bin/grpc_node_pluginYou can use an S3 bucket as a mirror, upload the tarball under the path
grpc-tools/v1.11.2/darwin-arm64.tar.gz(match the version to whatever version of grpc-tools you use), make it public, and thennpm install --grpc_tools_binary_host_mirror=https://<my-bucket>.s3.amazonaws.com/should work. You might also want to mirror the tarballs for other platforms, e.g.https://node-precompiled-binaries.grpc.io/grpc-tools/v1.11.2/darwin-x64.tar.gzandhttps://node-precompiled-binaries.grpc.io/grpc-tools/v1.11.2/linux-x64.tar.gzif you also use x86-64 Mac OS or Linux.
Did anyone succeed with this approach? I.e. making it possible to simply yarn yarn install and then it'll install grpc-tools regardlass of architecture.
@ldx I've got it working with npm install --grpc_tools_binary_host_mirror=https://<my-bucket>.s3.amazonaws.com/. Thanks for that tip.
Does anyone know the yarn equivalent (yarn install --grpc_tools_binary_host_mirror=https://<my-bucket>.s3.amazonaws.com/ does not work)? And is it possible to set some config so yarn install automatically will use the mirror if the package is not found in the official registry?
Can anyone explain where --grpc_tools_binary_host_mirror actually comes from? I can't find any documentation on it.
Update
Just found this issue - unfortunately no answer so not sure if it's possible with yarn.
Clone this repo, then cd grpc-node/packages/grpc-tools; git submodule update --init --recursive; ./build_binaries.sh should build the binaries. Make sure you have XCode/Command Line Tools installed.
@ldx Thank you, I've made it work with your solution. But in my environment (Oracle Cloud Ampere A1 Compute, Ubuntu-20.04) I needed to remove -m32 arguments from CMAKE_CXX_FLAGS, CMAKE_C_FLAGS, CMAKE_EXE_LINKER_FLAGS.
The following changes worked:
$ git diff packages/grpc-tools/linux_32bit.toolchain.cmake
diff --git a/packages/grpc-tools/linux_32bit.toolchain.cmake b/packages/grpc-tools/linux_32bit.toolchain.cmake
index 5a1b80f0..62347c7f 100644
--- a/packages/grpc-tools/linux_32bit.toolchain.cmake
+++ b/packages/grpc-tools/linux_32bit.toolchain.cmake
@@ -1,3 +1,3 @@
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")
-set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -m32" CACHE STRING "ld flags")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}" CACHE STRING "c++ flags")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}" CACHE STRING "c flags")
+set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}" CACHE STRING "ld flags")My environment:
$ uname -a
Linux instance-20220101-1510 5.11.0-1022-oracle #23~20.04.1-Ubuntu SMP Fri Nov 12 15:45:47 UTC 2021 aarch64 aarch64 aarch64 GNU/LinuxI was able to build it on an Apple Silicon Mac like so:
git clone git@github.com:grpc/grpc-node.git
cd grpc-node
brew install cmake # ./build_binaries.sh needs cmake. also tried xcode-select --install but it didn't seem to work
cd packages/grpc-tools && git submodule update --init --recursive && ./build_binaries.sh
# then to install in pnpm (does not support npm flag)
npm_config_grpc_tools_binary_host_mirror="https://github.com/maschwenk/grpc-node/raw/2dd28e1ab8211533007dd2df5ae632de60006983/artifacts/" pnpm install
# checkout https://github.com/mapbox/node-pre-gyp/blob/master/lib/util/versioning.js#L316
# seems passing as an ENV also works (so will probably work for PNPM and Yarn)You will also need to manually change packages/grpc-tools/build_binaries.sh to not set the arch to x64.
Can anyone explain where
--grpc_tools_binary_host_mirroractually comes from? I can't find any documentation on it.
@mr-bjerre you can pass it through the env
npm_config_grpc_tools_binary_host_mirror="https://github.com/maschwenk/grpc-node/raw/2dd28e1ab8211533007dd2df5ae632de60006983/artifacts/" yarn install
Note that it doesn't link directly to the file, but the folder containing the binaries
@mr-bjerre you can pass it through the env
npm_config_grpc_tools_binary_host_mirror="https://github.com/maschwenk/grpc-node/raw/2dd28e1ab8211533007dd2df5ae632de60006983/artifacts/" yarn installNote that it doesn't link directly to the file, but the folder containing the binaries
@maschwenk is my hero. I was subsequently, finally, able to get my Bazel workspace to build, simply by adding an environment bit to my WORKSPACE's yarn_install
yarn_install(
name = "npm",
package_json = "//:package.json",
yarn_lock = "//:yarn.lock",
environment = {
"npm_config_grpc_tools_binary_host_mirror": "https://github.com/maschwenk/grpc-node/raw/2dd28e1ab8211533007dd2df5ae632de60006983/artifacts/",
},
)
I figure I'll fork the grpc-node repo myself with Max's changes, so that I can build these artifacts myself when I need them updated for new versions. @maschwenk : could you clarify how mirrors work in the Yarn/NPM world? i.e. is the mirror only used if the central repository doesn't have the requested artifact? I ask because I want my code to support darwin-arm64 in addition to other architectures (for which there are grpc-utils artifacts already).
I figure I'll fork the grpc-node repo myself with Max's changes, so that I can build these artifacts myself when I need them updated for new versions.
π ππΌ definitely don't recommend using internet random's binaries.
@maschwenk : could you clarify how mirrors work in the Yarn/NPM world? i.e. is the mirror only used if the central repository doesn't have the requested artifact?
So I think what's happening is actually:
- https://docs.npmjs.com/cli/v8/using-npm/config#environment-variables only
npmsupports this conversion of flags prepended withnpm_configto configure theprocess.env node-pre-gypis using the ENV or something set in the package.json to find the binary. I believe the default behavior is just using what's defined in thebinarysection of a package.json, so we're intentionally overriding it with the ENV- Because not everyone uses
npm, you can just use a standard ENV injection to get # 2 to work
I was able to build it on an Apple Silicon Mac like so: ...
Thanks, @maschwenk, that helped a lot. I'm missing the bit on how to upload the binaries to github.
To create the artifact, I tried both:
npm packinsidegrpc-node/packages/grpc-toolstar -zcvf darwin-arm64.tar.gz bininsidegrpc-node/packages/grpc-tools/build.
I then upload each artifact (one at the time) into an empty repo under path artifacts/grpc-tools/v1.11.2/darwin-arm64.tar.gz but I'm getting TAR_BAD_ARCHIVE: Unrecognized archive format when trying to install using the env option. I'm wondering how you tarballed the files in the first place.
I'm using docker and npx as a workaround. It works pretty well.
docker run --rm --platform linux/amd64 \
-v `pwd`:'/app' \
-w '/app' node:16 npx \
-y --package=grpc-tools \
-- grpc_tools_node_protoc \
--js_out=import_style=commonjs,binary:./nodejs/ --grpc_out=grpc_js:./nodejs/ ./*.proto
I found a workaround by forcing terminal to x64 architecture and running the service
Commands
- env /usr/bin/arch -x86_64 /bin/zsh --login
- npm install
- and start your service
Note that architecture preference is only for given terminal window.
If anyone wants to know how to deal with this inside an arm64 Docker image running Ubuntu, please take a look at the final part of build.assets/Dockerfile-teleterm in my commit above that references this issue.
I added an arm64 CMake toolchain which is something that was missing. One thing to note is that while grpc-tools needs two binaries, protoc and grpc_node_plugin, our image already had protoc. If you want to compile both binaries, just remove the --target grpc_node_plugin flag from the final cmake call.
this issue would never have surfaced if a pre-built ARM binary had simply been published
most of the gRPC ecosystem builds on raw systems via Bazel and lower level tooling. why this doesn't, as an exception, makes no sense. surely there is somewhere within Google that isn't relying on Github Actions to use this code?
could google be so kind as to unbreak their node package ecosystem for most mac users?
for instance, is it possible to move this to CI infra where cross compiling is possible? or can node-gyp be supported to dynamically link against protoc on ARM, given that M1 has been out now for some time (November 2020), M2 is on the way, and x86 is not even for sale anymore for most Mac lines?
the entire point of gRPC is safe transport of data across systems which may differ in architecture. i don't understand what kind of barrier could possibly exist toward solving that problem; that is the reason this code exists
also @srabraham thank you for posting bazel instructions here, that's very helpful
This isn't even an M1 issue - just needs to provide a build for aarch64 / arm64. It does not need to be compiled on an M1, and arm64 system will provide a working binary. Not only are M1 users being forced to use sub-optimal x86 builds, but the entire Raspberry Pie community have been neglected.
We don't provide Linux arm64 binaries for the same reason that we don't provide Mac M1 binaries: we don't have the environment available to do the build. Protobuf is a pain to cross-compile because of how it bootstraps itself, so we are only providing binaries that we can build on the corresponding environment. M1 build machines are at least on the roadmap for GitHub Actions, so we expect to support them eventually, but Linux arm64 is not on that roadmap, so we have no plans to provide Linux arm64 binaries.
If you want to use a Raspberry Pie, I suggest performing the build on another machine and then transferring the output files to the Pie. The grpc-tools package is just a build tool; it is not needed at runtime.
@murgatroid99 Is this the item that is blocking the arm64 pipeline? If so it just shipped out and I just wanted to point it out and potentially give an update on this for the community.
Disregard that looks like it was the wrong item after doing some more reading. My bad.
We were able to do a local build, upload that to an S3 bucket, and then configure npm to look there for binaries.
Here's the rough steps to follow
- clone
grpc-node(including recursive submodules) - run
./packages/grpc-tools/build_binaries.sh- install dependencies until this works (we only found we needed
jqandcmake)
- install dependencies until this works (we only found we needed
- upload the tarball from
./artifactsto your S3 bucket, marking it as public - it needs to keep the same path in the bucket as it had inartifacts- for us that wasgrpc-tools/v1.11.2/ - configure
npmto prefer our S3 bucket for the binaries by adding the following to.npmrcin the repogrpc_tools_binary_host_mirror=https://YOURBUCKETNAME.s3.amazonaws.com/nodejs-precompiled-binaries/
We also did the same thing for grpc-node's native package, only that was easier to build as we could use the node-pre-gyp automatic source fallback and then node-pre-gyp package to create the tarball.
@Mills-2 Could you expand on why it wouldn't work? I did a local compile on my M1, and it works if I use @glenjamin's solution, but before diving into this and providing a PR I'd love to know what the blocker would have been.
My understanding is that the project doesn't want to provide pre-compiled binaries that were not created by a publicly visible CI provider.
So while it's possible to create binaries in an ad-hoc manner on individual M1 machines, there isn't yet a good way to hook this into the automated build tooling for the project.
@glenjamin yea that makes sense, but Github's M1 agents that @Mills-2 linked to would hypothetically work?
Thanks for the suggestion btw, @glenjamin, works great for us so far.
@janpieterz The issue I linked is for self-hosted runners. This issue is blocked by github hosted runners. It is still in future implementation on the roadmap for github.
I'm happy to donate an arm mac to the grpc team for the self hosted runner.
Version 1.11.3 now has Mac M1/arm64 binaries.
A great notification to wake up to. Thanks to all the people who made that happen.
Any chance the latest version can be published to NPM as well?
Edit: was just looking at the wrong package @grpc/grpc-js. Of course this was about grpc-tools
The latest version is 1.11.3 and it is on NPM.
@murgatroid99 I updated to that new version and it worked a treat. Thank you!
Version 1.11.3 now has Mac M1/arm64 binaries.
Updated too and works great now without any work arounds. Thank you! π
Still missing linux arm64 binary π’
https://node-precompiled-binaries.grpc.io/grpc-tools/v1.11.3/linux-arm64.tar.gz
Version 1.11.3 now has Mac M1/arm64 binaries.
Still not available for linux (exp: if you have a docker image):
response status 404 Not Found on https://node-precompiled-binaries.grpc.io/grpc-tools/v1.11.3/linux-arm64.tar.gz
so I've added the following to my dockerfile
RUN npm_config_target_arch=x64 npm i grpc-tools
@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?
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:
npm_config_target_arch=x86 npm i grpc-tools
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...
https://github.com/ZCube/grpc-precompiled-binaries
A while back we made an alternative mirror for this... https://github.com/ZCube/grpc-precompiled-binaries
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οΌ
...
[ 99%] Linking CXX executable protoc
[100%] Linking CXX executable grpc_node_plugin
/usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
gmake[2]: *** [grpc_node_plugin] Error 1
gmake[1]: *** [CMakeFiles/grpc_node_plugin.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[100%] Built target protoc
gmake: *** [all] Error 2
ldconfig -p | less
libstdc++.so.6 (libc6,AArch64) => /lib64/libstdc++.so.6
libstdc++.so (libc6,AArch64) => /usr/local/lib/libstdc++.so
libssl3.so (libc6,AArch64) => /lib64/libssl3.so
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
node-pre-gyp info it worked if it ends with ok | 88s
-- | --
86 | node-pre-gyp info using node-pre-gyp@1.0.10 | 88s
87 | node-pre-gyp info using node@16.17.1 \| linux \| x64 | 88s
88 | node-pre-gyp info check checked for "/drone/src/node_modules/grpc-tools/bin/grpc_tools.node" (not found) | 88s
89 | node-pre-gyp http GET https://node-precompiled-binaries.grpc.io/grpc-tools/v1.12.3/linux-x64.tar.gz | 88s
90 | node-pre-gyp ERR! install request to https://node-precompiled-binaries.grpc.io/grpc-tools/v1.12.3/linux-x64.tar.gz failed, reason: read ECONNRESET | 88s
91 | node-pre-gyp ERR! install error
@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
Successful build: https://github.com/RedstoneWizard08/grpc-node/actions/runs/3981949215/jobs/6826020346
PR: #2333
Merged!
The Linux ARM64 binary is now available in version 1.12.4.
Is it planned to support M2 architecture as well?
The latest version is 1.11.3 and it is on NPM.
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?