-
Notifications
You must be signed in to change notification settings - Fork 2
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
Project fails to compile on ARM64 #310
Comments
Would be really great to see arm64 arch supported by this buildpack. Perhaps an environment variable for now to select the target arch? |
@abarke Hi! So this issue as filed is for the problem that it's not possible to work on the buildpack (eg: compile it locally) on an ARM64 machine. Actually supporting ARM64 at runtime when the buildpack builds an app is a separate thing to solve - and will be much harder given that it will first need (a) support from Pack CLI/lifecycle (buildpacks/lifecycle#435 / buildpacks/pack#1171), (b) ARM64 Heroku stack image variants (but that's also something that needs to be done carefully, see heroku/base-images#194). |
Gotcha @edmorley I thought I was in the official heroku node.js buildpack. My apologies. In any case it would be great to see CNB support for multiple targets including arm64 and any future targets that may materialize. |
@edmorley side question: would it be easy enough to add support for multiple runtime targets to the official heroku node.js buildpack? I have been experimenting with deploying node.js code to arm64 and it's going well. Up until now we just download a compatible node.js binary for arm64 and use that to run the app. Works a treat. The next step would be to either write our own buildpacks (not gonna happen) for app deployment, fork the official buildpack (plausible) or contribute to the official buildpack (ideal) and allow everyone to benefit, should Heroku support arm64 runtimes in the future. |
For languages where the buildpack uses the upstream binaries (like Node.js or Go do), adding support to the buildpack should be fairly easy - a conditional to just adjust the URL used etc. For languages where we have to build our own binaries, it will be a bit more involved, so likely not worth it until more of the rest of the CNB pieces are close to supporting multi-arch. In addition, adding support to the buildpack first is actually necessary, since if we were say to add ARM64 Heroku stack image variants prior to that, any buildpack that wasn't architecture-aware would then start failing on alternate architectures. |
Exactly, we already support a arm64 stack and dyno internally, so the missing piece for us is the buildpack. As the majority of our apps are Node.js we would be able to migrate the majority of our apps to ARM fairly efficiently. I will look into a PR for the buildpack to support an optional target for the downloaded node.js binary. That should be sufficient for our needs. |
Trying to compile the Rust buildpacks on my ARM64 MacBook M1 (eg via
cargo test
), I get:This is due to:
buildpacks-nodejs/common/nodejs-utils/src/inv.rs
Line 18 in 7454fbe
Whilst that conditional is fine when cross-compiling, it breaks things when compiling for the host (eg
cargo check
,cargo clippy
,cargo test
workflows).cc @joshwlewis @colincasey
The text was updated successfully, but these errors were encountered: