heroku-buildpack-nodejs icon indicating copy to clipboard operation
heroku-buildpack-nodejs copied to clipboard

Add ARM support for resolve-version

Open mlarraz opened this issue 1 year ago • 2 comments

  • Copies the existing resolve-version-linux and resolve-version-darwin to resolve-version-linux-x64 and resolve-version-darwin-x64
  • Adds new Makefile steps to build these for ARM
  • Rewrite get_cpu() bash function to support ARM (and drop support for i686)
  • Use existing get_platform() function instead of get_os() to determine filename

I have not actually managed to build the new binaries myself as I'm not very experienced with Rust, but hoping somebody can help out.

I noticed there's a similar thing happening for yq but I didn't see any code handling the vendoring so I assume it was done manually. Presumably it will need ARM versions as well

This is meant to fix https://github.com/heroku/heroku-buildpack-nodejs/issues/1268

mlarraz avatar Sep 10 '24 20:09 mlarraz

@mlarraz thanks for the PR! I won't be able to fully review this until sometime next week due to other priorities but it looks like a good first step in addressing #1268.

As for the cross-compilation of the resolve-version binaries, that's a bit more complicated since the setup varies depending on the host/target but typically you need the following:

  • The standard library for the target installed with rustup target add {target} (e.g.; rustup target add aarch64-apple-darwin)
  • A linker for the platform (e.g.; brew install messense/macos-cross-toolchains/aarch64-unknown-linux-musl on Mac, sudo apt-get install g++-aarch64-linux-gnu libc6-dev-arm64-cross musl-tools on Linux)
  • It may also be necessary to set some environment variables so that cargo uses the correct toolchain (e.g.; CARGO_TARGET_AARCH64_UNKNOWN_LINUX_MUSL_LINKER and/or CC_AARCH64_UNKNOWN_LINUX_MUSL)

And you're right, the vendored yq binaries were manually sourced from their releases.

colincasey avatar Sep 11 '24 13:09 colincasey

Thanks, I will work on adding the binaries.

I noticed a previous commit referenced compressing the yq binaries, but didn't go into detail. It doesn't look like it was using tar or some other container as the files are still directly executable.

mlarraz avatar Sep 11 '24 13:09 mlarraz

Ugh, this fell off my radar as there's no priority to support ARM for our classic buildpacks. I'm going to convert this PR to a draft for now with the hope of returning to it.

colincasey avatar Feb 27 '25 13:02 colincasey

Closing this as #1268 was always a "nice to have" but I don't think it's worth the effort at this time.

colincasey avatar Aug 06 '25 13:08 colincasey