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 :)

[mollux]

@rvagg any update on this issue? What's the blocker to get it merged?

[mollux]

Based on https://github.com/nodejs/unofficial-builds?tab=readme-ov-file#team, pinging some more people to see if there is actually someone still active in the project:

@richardlau @sxa @shipujin @matthewkeil what's needed to move this PR forward?

[sxa]

@richardlau @sxa @shipujin @matthewkeil what's needed to move this PR forward?

The thing that makes me a bit nervous is the compilation of the cross-compiler when the dockerfile is built when the dockerfile is run which is inconsistent with how it's done elsewhere. I'll see if others want to comment on this approach, although I'm inclined to agree with @rvagg's earlier comment: maybe we should cache a copy of this locally and reuse it when we rebuild

However I will also note that compared to the time to run a full Node.js build it's not that significant :-)

[mollux]

@sxa I agree with that, but for me that's an optimization (see #189 (comment)), as it's impact or solution (where to store the cache?) is not visible from the outside.

This PR ensures a very practical use-case becomes possible: using nodejs on alpine based (more correct distro's using MUSL) on arm64 hardware (in practice the newer Macbooks), see also the original PR.

This PR is now blocked for a month and a half on something where the impact is not clear or visible, so how can we help?

[sxa]

@mollux I had a test on my machine and can confirm that this does appear to work ok and gives me something that will compile and run process.version in the resulting node. I agree with the mac/aarch64/alpine usecase being one worth having in the unofficial builds area. I'll leave this open for another day or so before we merge but in principle I'm happy with this change.

[sxa]

@mollux Would it be possible to lock this to a specific hash of the code in https://github.com/richfelker/musl-cross-make ?
I note the change from the earlier PR to obtain the cross-compiler via a different mechanism (Change) and while I haven't personally looked at the repository from a security perspective I think it would be good at a minimum to ensure we are protected against potential rogue changes in that repository, even though this is the unofficial-builds repository.

[mollux]

@sxa yes, that makes sense, I will check if I can use the latest known release, or otherwise pin it to the last master branch commit.

[mollux]

@sxa I tested the latest tag (v0.9.11), but it was not working, so I used the last commit on master.

This is the same version that I've been testing with for the past months, as there are no extra commits since end of July.

I compiled v22.21.1, v24.11.0 and v26.0.0-nightly2025110883c05d4304 without issues

[mollux]

@sxa any update on this? I made the needed changes.

[sxa]

@sxa any update on this? I made the needed changes.

I was having an offline discussion about this one earlier today and I've just done a final test myself on this so I think it's good to go in the absence of any further recent comments 👍🏻

[mollux]

@sxa thanks!

[nikolaik]

Wonderful 👏