[REQUEST] arm64 support #186
Comments
|
Didn't check what the github actions for this repo are doing, but this could also help in the future |
|
A few notes.
|
|
Thanks for your insight, @Sparticuz. I'll aim to circle back around to looking at this -- I had encountered issues during the compilation process (described above) and needed to push on with another way forward just for now. Cross-compiling for arm64 is the only option as I've discovered due to a lack of support in Chromium's build processes, but I also encountered issues during the cross-compile on For now I just wanted to list out the list of packages and libraries that Chromium needs at runtime at least (I'm using the chromium arm64 build from Playwright and that's working well on AL2023). I've got the following building a Layer via SAM, which is running the 'build' in a dnf install -y \
alsa-lib \
at-spi2-atk \
at-spi2-core \
atk \
avahi-libs \
cairo \
cups-libs \
dbus-libs \
expat \
freetype \
fontconfig \
fribidi \
google-noto-sans-vf-fonts \
google-noto-serif-vf-fonts \
graphite2 \
gnutls \
harfbuzz \
libX11 \
libXau \
libXcomposite \
libXcomposite \
libXdamage \
libXext \
libXfixes \
libXi \
libXrandr \
libXrender \
libbrotli \
libdatrie \
libdrm \
libgudev \
libpng \
libthai \
libwayland-server \
libxcb \
libxkbcommon \
mesa-libgbm \
nettle \
nspr \
nss \
nss-util \
p11-kit-trust \
pango \
pixman \
systemd-libs
mkdir -p "/tmp/lib"
cp -P /usr/lib64/{\
libasound,\
libatk-bridge-2.0,\
libatspi,\
libatk-1.0,\
libavahi-client,\
libavahi-common,\
libcairo,\
libcups,\
libdbus-1,\
libexpat,\
libfreetype,\
libfontconfig,\
libfribidi,\
libgraphite2,\
libgnutls,\
libharfbuzz,\
libX11,\
libXau,\
libXcomposite,\
libXdamage,\
libXext,\
libXfixes,\
libXi,\
libXrandr,\
libXrender,\
libbrotlicommon,\
libbrotlidec,\
libdatrie,\
libdrm,\
libudev,\
libpng16,\
libthai,\
libwayland-server,\
libxcb,\
libxcb-render,\
libxcb-shm,\
libxkbcommon,\
libgbm,\
libnettle,\
libhogweed,\
libnspr4,\
libplc4,\
libplds4,\
libnss3,\
libsmime3,\
libssl3,\
libnssutil3,\
libsoftokn3,\
libfreeblpriv3,\
libnssckbi,\
libpango-1.0,\
libpixman-1,\
libsystemd\
}.* "/tmp/lib"
set -e; \
cd /tmp/lib; \
tar -cf al2023.tar *; \
brotli --best --force al2023.tar |
This comment was marked as spam.
This comment was marked as spam.
|
+1 |
|
+1 |
|
I seem to have managed to compile a binary for ARM64 AWS Lambda https://github.com/remotion-dev/chrome-build-instructions/blob/main/V2.md Hope this is helpful, probably some more work is required to get it working with this project. |
Awesome! I am traveling the next few weeks, but will try to look at this asap!! |
This comment was marked as spam.
This comment was marked as spam.
|
I was able to compile Chromium for AWS Lambda on the ARM64 architecture Amazon Linux 2 (NodeJS 16 & NodeJS 18): Amazon Linux 2023 (NodeJS 20): |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
|
Is there any another block now for building binaries in arm64? ARM64 GitHub runners are now in GA and they cost even less compared to x86 |
This comment was marked as spam.
This comment was marked as spam.
What would you like to have implemented?
Builds of Chromium for both x86_64 and arm64.
I know this has been discussed a lot previously in #93 and #19 but with the general availability release of
provided.al2023for Lambda (https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/), this now seems feasible given previous discussions around blockers.I wanted to open the discussion around adding this support as some changes would be needed to the build & release processes to handle both architectures. Mostly, I wanted to see what help I could be with that process, to document my findings so far, and contribute PRs/fixes for issues in the compilation process where possible.
Why would it be useful?
arm64-based AWS Lambda function invocation is notably cheaper thanx86_64, but also having anarm64version of Chromium allows for situations such as where emulation ofx86_64isn't possible or problematic on ARM CPUs (e.g. local invocation of functions via AWS SAM).Other info
I'm currently running the Ansible playbook from this repo against both
c6i.16xlargeandc6g.16xlargeinstances for x86_64 and arm64 respectively. It's taken over an hour just to clone the Chromium source (at least 44GB of data), but I'll report the issues I'm encountering on either environment below.Status so far
aws.tar.brbuilt and updated?x86_64 host
x64build: successfully on AL2023 with current Ansible playbookarm64build: in progressRequires
target_cpu=["x64", "arm"]to be added to.gclientconfigurationRequires
gnto be set up like sogn gen out/Default --args="target_cpu=\"arm64\""autoninja -C out/Default chromeerrors:export LDFLAGS="-z max-page-size=0x10000"due to Unable to build arm64 binaries (segfault during v8 bytecode_builtins_list_generator) envoyproxy/envoy#17100ARM64/Gravitron host
Given the below and general notes at https://chromium.googlesource.com/chromium/src/+/main/docs/linux/chromium_arm.md, it appears that cross-compiling for ARM is the only option at present.
The text was updated successfully, but these errors were encountered: