You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are however recent v24 LTS builds for riscv64. But since v24.22.0 they throw segmentation faults (node -h and every other call aside of node -v), verified on a physical system as well as via QEMU riscv64 emulation. I can add a strace if it helps.
The latest v26.12.1 riscv64-pointer-compression builds work fine, but v24.22.0 and v24.22.1 riscv64-pointer-compression throw segmentation faults as well. So it seems to be something limited to recent v24, but affecting all riscv64 build variants.
So I suggest adding the pointer-compression builds to the index.tab and index.json. And if there is anything I can help with debugging/testing v24.22.x riscv64 builds, let me know. Would be great if we had functional LTS builds with latest security patches.
if there is anything I can help with debugging/testing v24.22.x riscv64 builds, let me know.
If you can narrow it down to a specific commit that could be useful in order to see how to fix it. It's not necessarily relevant but which physical board were you running on (Specifically was it one with vector instructions?)
We've been tracking various RISC-V related stuff in nodejs/build#4099 and various linked issues although I wasn't aware that it was broken at the moment so thanks for raising this one.
Would be great if we had functional LTS builds with latest security patches.
Just to reiteration that these are unofficial builds on a platform listed as experimental, so I wouldn't consider that it's an "LTS" with any sort of support expections at this time :-)
So I suggest adding the pointer-compression builds to the index.tab and index.json
If you can narrow it down to a specific commit that could be useful in order to see how to fix it.
So far I just tested the available compiled builds, to narrow it down to something between v24.21.0 and v24.22.0. To narrow it down to a commit, I'd need to review the commit history, or do a lot of own builds. I'm afraid I do not have enough insights/experience with the source code structure etc to effectively know what to watch out for.
It's not necessarily relevant but which physical board were you running on (Specifically was it one with vector instructions?)
I recognized it in CI/CD pipeline with QEMU riscv64 emulation, and verified + narrowed it down to v24.22.0 on a PINE64 Star64 with StarFive JH7110 SoC.
Just to reiteration that these are unofficial builds on a platform listed as experimental, so I wouldn't consider that it's an "LTS" with any sort of support expections at this time :-)
But LTS still means a major version which gets security updates for a long time, and is mode widely supported by downstream software, compared to latest stable.
I'll have a look at the build.sh. So far I do not see why it is skipped. run.sh passes VARIATION="pointer-compression", the x64-pointer-compression recipe has run-other.sh which sets variation=pointer-compression instead, but the Dockerfile still calls a run.sh from somewhere. Need to check the practical difference this causes.
Although nodejs-dist-indexer was updated to index risv64 pointer compression builds, we didn't correspondingly update this repository to pick up a version of nodejs-dist-indexer with the change. Proposed fix in #257
So far I just tested the available compiled builds, to narrow it down to something between v26.12.1 and v24.22.0. To narrow it down to a commit, I'd need to review the commit history, or do a lot of own builds.
From memory I think it took over 24 hours to build node on a JH7110 without a populated ccache - maybe a bit less for v24. Do you know which specific version in the v24 stream it started breaking in? I'm reasonably sure it used to work on older versions of v24. You can check what went into one version from the next with something like nodejs/node@v24.21.0...v24.22.0 although for v24 that can still be quite a lot of commits. For crashes I'd typically look for any V8 backports or maybe some other dependencies being updated that might have caused a problem.
But LTS still means a major version which gets security updates for a long time, and is mode widely supported by downstream software, compared to latest stable.
Yep I agree but just wanted to clarify that expectations were set accordingly ;-)
Do you know which specific version in the v24 stream it started breaking in?
With v24.22.0 precisely. v24.21.0 works fine. I mixed up the tags above, edited. The 3 V8 backports merged with v24.22.0 (skipping one which affects AIX platforms only):
I guess an strace would help to know where exactly it crashes? The number of changes overall is huge.
Yep I agree but just wanted to clarify that expectations were set accordingly ;-)
Absolutely fine. I maintain open source projects myself and do not have any expectations when using OSS for free, without any contract, where the license unambiguously states:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
And then these are unofficial builds. But I am actively working on riscv64 support, adding builds to CI/CD pipelines in various projects we use/provide in my main project. The architecture absolutely deserves better/faster support within the open source community. So wherever I face issues, I report them, and try to fix them where I can 🙂.
Looks like the first link there gives a 404. The third one has some changes in platform-specific files though 🤔
guess an strace would help to know where exactly it crashes?
I suspect a backtrace from a core dump might be more useful to figure out where in the code it's coming from - It's unlikely (but not impossible so feel free to try it and see if it gives any hints) that it's in any system call that we'd be able to identify from strace.
Confirmed (via rebuilds on a JH7110!) that it was introduced in by the changes to macros-assembler-riscv.cc (specifically the changes to the Push() arguments) in nodejs/node@fb0d0ca (Associated issue is nodejs/node#62393 (comment))
Just noting for reference that when building without that commit reversed if a full native build it run with the normal build tagets used in the CI it falls over when building the addons, but doesn't explicitly display a segfault message:
18:11:26 Building addon in /home/iojs/workspace/node-test-commit-rvlinux/nodes/rv64gcv/benchmark/napi/function_call
18:11:26 Building addon in /home/iojs/workspace/node-test-commit-rvlinux/nodes/rv64gcv/benchmark/napi/function_args
[...]
18:11:26 Failed to build addon in /home/iojs/workspace/node-test-commit-rvlinux/nodes/rv64gcv/benchmark/napi/function_call:
18:11:26 make[1]: *** [Makefile:511: benchmark/napi/.buildstamp] Error 1
18:11:26 make: *** [Makefile:640: run-ci] Error 2
18:11:27 Build step 'Execute shell' marked build as failure
Activity
sxa commentedon Nov 2, 2026
If you can narrow it down to a specific commit that could be useful in order to see how to fix it. It's not necessarily relevant but which physical board were you running on (Specifically was it one with vector instructions?)
We've been tracking various RISC-V related stuff in nodejs/build#4099 and various linked issues although I wasn't aware that it was broken at the moment so thanks for raising this one.
Just to reiteration that these are unofficial builds on a platform listed as experimental, so I wouldn't consider that it's an "LTS" with any sort of support expections at this time :-)
That will be somewhere in the code launched by
unofficial-builds/bin/build.sh
Line 149 in 31872d7
MichaIng commentedon Nov 2, 2026
So far I just tested the available compiled builds, to narrow it down to something between v24.21.0 and v24.22.0. To narrow it down to a commit, I'd need to review the commit history, or do a lot of own builds. I'm afraid I do not have enough insights/experience with the source code structure etc to effectively know what to watch out for.
I recognized it in CI/CD pipeline with QEMU riscv64 emulation, and verified + narrowed it down to v24.22.0 on a PINE64 Star64 with StarFive JH7110 SoC.
But LTS still means a major version which gets security updates for a long time, and is mode widely supported by downstream software, compared to latest stable.
I'll have a look at the
build.sh. So far I do not see why it is skipped.run.shpassesVARIATION="pointer-compression", thex64-pointer-compressionrecipe hasrun-other.shwhich setsvariation=pointer-compressioninstead, but the Dockerfile still calls arun.shfrom somewhere. Need to check the practical difference this causes.richardlau commentedon Nov 2, 2026
Although
nodejs-dist-indexerwas updated to index risv64 pointer compression builds, we didn't correspondingly update this repository to pick up a version ofnodejs-dist-indexerwith the change. Proposed fix in #257sxa commentedon Nov 2, 2026
From memory I think it took over 24 hours to build node on a JH7110 without a populated ccache - maybe a bit less for v24. Do you know which specific version in the v24 stream it started breaking in? I'm reasonably sure it used to work on older versions of v24. You can check what went into one version from the next with something like nodejs/node@v24.21.0...v24.22.0 although for v24 that can still be quite a lot of commits. For crashes I'd typically look for any V8 backports or maybe some other dependencies being updated that might have caused a problem.
Yep I agree but just wanted to clarify that expectations were set accordingly ;-)
MichaIng commentedon Nov 2, 2026
With v24.22.0 precisely. v24.21.0 works fine. I mixed up the tags above, edited. The 3 V8 backports merged with v24.22.0 (skipping one which affects AIX platforms only):
I guess an strace would help to know where exactly it crashes? The number of changes overall is huge.
Absolutely fine. I maintain open source projects myself and do not have any expectations when using OSS for free, without any contract, where the license unambiguously states:
And then these are unofficial builds. But I am actively working on riscv64 support, adding builds to CI/CD pipelines in various projects we use/provide in my main project. The architecture absolutely deserves better/faster support within the open source community. So wherever I face issues, I report them, and try to fix them where I can 🙂.
sxa commentedon Nov 2, 2026
Looks like the first link there gives a 404. The third one has some changes in platform-specific files though 🤔
I suspect a backtrace from a core dump might be more useful to figure out where in the code it's coming from - It's unlikely (but not impossible so feel free to try it and see if it gives any hints) that it's in any system call that we'd be able to identify from
strace.MichaIng commentedon Nov 2, 2026
7 digits were not enough for the 1st commit hash. Fixed.
sxa commentedon Nov 3, 2026
It was definitely introduced by one of those three commits :-)
sxa commentedon Nov 3, 2026
Confirmed (via rebuilds on a JH7110!) that it was introduced in by the changes to
macros-assembler-riscv.cc(specifically the changes to thePush()arguments) in nodejs/node@fb0d0ca (Associated issue is nodejs/node#62393 (comment))sxa commentedon Nov 3, 2026
Just noting for reference that when building without that commit reversed if a full native build it run with the normal build tagets used in the CI it falls over when building the addons, but doesn't explicitly display a segfault message: