-
Notifications
You must be signed in to change notification settings - Fork 31
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
aarch64 build #69
Comments
I added gettext, and the build is continuing now... |
It's based on Wheezy intentionally to support a really old You don't necessarily need ARM hardware to compile to ARM either, my plan was to use cross-compiler tools. I'd absolutely love it if someone got that working! It just involves getting the right compiler and setting |
Thanks for the prompt reply. I assume that your goal by keeping libc old is to achieve maximum coverage of Linux distros. Are there any other benefits of your current libc choice? From my digging, Wheezy uses eglibc 2.13. Wheezy and eglibc are both discontinued - so I would like to make the case to consider an upgrade :) |
Yeah, I should have said that, it's to support older distros since executables are compatible with newer libc but not older (I guess because they add symbols but never remove them). If you look through the issues there were a lot of problems when I compiled against a new libc. Even today #44 remains open because someone is using CentOS 6.9, which a still-supported distro that uses a libc from 2010 and I couldn't go that far back.
It shouldn't matter, though since the binaries we ship will link against whichever libc you have on your distro. So all that said, the only options I can think of are to either try and compile an old libc on a new distro or try and get cross-compiling working with Wheezy. |
Thanks for your thoughts. I started this thread because I think AArch64 (announced by Arm in 2011) is the most popular Arm architecture to run node-canvas-prebuilt in production. I had a look at compiling libc 2.13 (from 2010) and it confidently asserts: configure: error: The aarch64 is not supported. It looks like one would need to go to libc 2.17 (from 2012) to get aarch64 support. There certainly are armhf platforms around (i.e. rpi). I see a discussion on that topic here: #9 To avoid confusion, I guess discussion of the armhf build should take place against #9 ? |
Nodejs supports We could maybe just have a completely separate docker image for ARM builds that runs on a newer OS+libc. I wish a new compiler could just target a libc version but it doesn't look easy to do that. If we found out that nodejs binaries support a newer libc than the one I'm supporting, I'd be okay with upgrading Wheezy too, but I haven't figured out how to determine that yet. |
I also mentioned this in issue 9, but I need an arm64 build for Linux on DEX with the Galaxy S10+ |
Is there any update on this. Since M1 has native docker support canvas get issues with docker images in arm64 platform |
Hi @chearon,
As per your invitation in README.md, I would find an AArch64 (aka Arm64) build useful!
I had a look at Dockerfile. The Wheezy base image dependency is inconvenient: it is an unsupported version and not readily available on AArch64. I substituted Stretch for Wheezy and removed the 4.7 version hold on g++. It got as far as the glib compile and then:
I got distracted and haven't looked further after that.
NOTE: In terms of CI/CD systems that have Aarch64 as a supported architecture, I know of (in no particular order):
Shippable.com
http://docs.shippable.com/platform/tutorial/workflow/run-ci-builds-on-arm/#running-jobs-on-arm-machines
CodeFresh.io
https://codefresh.io/docs/docs/incubation/arm-support/
Drone.io
https://docs.drone.io/config/pipeline/multi-platform/
Resin.io
https://www.balena.io/docs/reference/base-images/base-images/#-a-name-what-is-inside-a-what-s-inside-a-balena-base-image
The text was updated successfully, but these errors were encountered: