Skip to content
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

Closed
edmorley opened this issue Jul 21, 2022 · 6 comments · Fixed by #359
Closed

Project fails to compile on ARM64 #310

edmorley opened this issue Jul 21, 2022 · 6 comments · Fixed by #359
Assignees

Comments

@edmorley
Copy link
Member

Trying to compile the Rust buildpacks on my ARM64 MacBook M1 (eg via cargo test), I get:

error[E0425]: cannot find value `ARCH` in this scope
  --> common/nodejs-utils/src/inv.rs:45:45
   |
45 |         let platform = format!("{}-{}", OS, ARCH);
   |                                             ^^^^ not found in this scope
   |
help: consider importing this constant
   |
1  | use std::env::consts::ARCH;
   |

This is due to:

#[cfg(target_arch = "x86_64")]

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

@abarke
Copy link

abarke commented Aug 1, 2022

Would be really great to see arm64 arch supported by this buildpack. Perhaps an environment variable for now to select the target arch?

@edmorley
Copy link
Member Author

edmorley commented Aug 1, 2022

@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).

@abarke
Copy link

abarke commented Aug 1, 2022

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.

@abarke
Copy link

abarke commented Aug 1, 2022

@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.

@edmorley
Copy link
Member Author

edmorley commented Aug 1, 2022

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.

@abarke
Copy link

abarke commented Aug 1, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants