add recipe to compile an arm64-musl version

[mollux]

This is the successor of #59, which also contains additional info and the discussion history.

This PR contains the needed changes to compile an arm64 musl version of currently supported nodejs versions.

I tested this by building multiple versions of nodejs, and running those in an Alpine container:

• v20.19.5
• v22.19.0
• v24.8.0
• v25.0.0-nightly20250914c8c6bfab2

All of those versions build successfully using GCC 14.2.0, using the local-build.sh script, e.g.

bin/local_build.sh -r arm64-musl -v v24.8.0

This is an updated comment, the initial version (and the PR) also contained info about compiling unsupported versions (v16 and v18).
I removed that part, based in the comments below.

[rvagg]

Has someone attempted to upstream the patches in here?

[mollux]

@rvagg I had some good succes last night compiling the musl toolset, so patches for supported versions are no longer needed 🥳 . I was able to compile 20, 22, 24 and 25-nightly.

I'll update this pr tonight, but all should be working for supported versions, and a decision need to be made is support for 18 and 16 should be added too (for at least the final release)

[rvagg]

don't add 18 or 16, those are unsupported upstream so we shouldn't bother here unless someone really wants to bend over backward but I suspect it'll be more trouble than it's worth and might suggest "support"

[mollux]

Agreed:) will update PR tonight!

[mollux]

@rvagg I updated the PR so it only contains support for supported versions :)

All issues with nodejs v24 and newer are also resolved by switching to a newer GCC version (from 11.2 to 14.2)

[rvagg]

how long does this take to compile? is this going to add a lot to our rebuild process whenever we update?

[mollux]

Depends on the resources :)

That specific step takes around 380 seconds (with 10 cores) on my local machine.

On my test server it takes a bit longer (666 seconds)

mattias@docker-builder:~/node_compiler/unofficial-builds/recipes/arm64-musl$ time docker build -t test .
[+] Building 678.8s (12/12) FINISHED                                       docker:default
 => [internal] load build definition from Dockerfile                                 0.0s
 => => transferring dockerfile: 1.23kB                                               0.0s
 => [internal] load metadata for docker.io/library/alpine:3.22                       0.0s
 => [internal] load .dockerignore                                                    0.0s
 => => transferring context: 2B                                                      0.0s
 => [1/6] FROM docker.io/library/alpine:3.22                                         0.0s
 => [internal] load build context                                                    0.0s
 => => transferring context: 28B                                                     0.0s
 => CACHED [internal] preparing inline document                                      0.0s
 => CACHED [2/6] RUN addgroup -g 1000 node     && adduser -u 1000 -G node -s /bin/s  0.0s
 => [3/6] RUN apk add --no-cache         libstdc++     && apk add --no-cache --virt  6.2s
 => [4/6] COPY <<-EOF /config/config.mak                                             0.0s  
 => [5/6] RUN git clone https://github.com/richfelker/musl-cross-make /musl-cross  666.4s 
 => [6/6] COPY --chown=node:node run.sh /home/node/run.sh                            0.0s  
 => exporting to image                                                               6.1s
 => => exporting layers                                                              6.1s
 => => writing image sha256:2681a96946dd126f0c762a7fd43a0fb16dcaace96ff821fe78299d8  0.0s
 => => naming to docker.io/library/test                                              0.0s
 
real    11m19.193s
user    0m1.622s

[rvagg]

948.5s on the machine where this needs to run, 15 minutes, that kind of sucks
not the end of the world, we only run docker build when we merge here but this is going to hold everything else up when it needs to rerun
maybe we should cache a copy of this locally and reuse it when we rebuild, we could probably mount some var directory like we do with .ccache, or even use .ccache in here to store it .. maybe

[mollux]

This would mean altering the place where the docker build is called. I can look into this if the .ccache approach would work here

[mollux]

unofficial-builds/bin/prepare-images.sh

Line 11 in 8fb00ef

docker build "${recipes_dir}/${recipe}/" -t "${image_tag_pfx}${recipe}" --build-arg UID=1000 --build-arg GID=1000

currently has currently no mounts (for caching or others).

Would it make sense to split this off to a separate issue / PR? As this is is a speed optimisation, and is also usable for other recipes

[rvagg]

mmm, no mounts during build
No need for a separate issue for now, let me think about this for a bit, it's not ideal but it's not the end of the world either.

[mollux]

@rvagg anything I can do to help move this PR forward?

[mollux]

@rvagg another bump of this PR :)