Repository navigation
armv7l package requires libatomic.so.1 since 12.16.0 but not documented #37219
Description
- Version: >= 12.16.0
- Platform: Linux armv7l
- Subsystem: build/deps
armv7l
$ readelf -d node-v12.15.0-linux-armv7l/bin/node
Dynamic section at offset 0x1de7748 contains 31 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
$ readelf -d node-v12.16.0-linux-armv7l/bin/node
Dynamic section at offset 0x1e3f728 contains 32 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [libatomic.so.1]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
x64
$ readelf -d node-v12.16.0-linux-x64/bin/node
Dynamic section at offset 0x2508da8 contains 31 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
arm64
$ readelf -d node-v12.16.0-linux-arm64/bin/node
Dynamic section at offset 0x232ed90 contains 32 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-aarch64.so.1]
Activity
deepak1556 commentedon Feb 4, 2021
Used 12.16.0 as example to show when the regression started, the issue is present with latest stable too. Based on the changes that went in only #30099 looks relevant, but I am not sure why it affected only armv7l.
Also based on x64 and arm64 output, looks like the library is not a necessary one, probably an issue in the compiler toolchain ? Also this change was not called out in the release notes, so I am not sure if this is intentional change.
[-]armv7l package requires libatomic.so.1 since 12.16.0[/-][+]armv7l package requires libatomic.so.1 since 12.16.0 but not documented[/+]mscdex commentedon Feb 4, 2021
I'm guessing the build environment used for armv7 releases changed.
/cc @nodejs/build
richardlau commentedon Feb 4, 2021
It looks like #31041 would be the most likely change.
deepak1556 commentedon Feb 4, 2021
Yup thats seems to be the change.
Based on the discussion in that PR, looks like change was made to support a particular toolchain, is this change going to be kept moving forward ?
We noticed this in our app where we bundle prebuilt node to run on the remote machine https://github.com/microsoft/vscode/blob/master/remote/.yarnrc#L2 (the version is quite old due to other factors), hence we noticed this quite late but wanted to bring it up since it looks like a breaking change which was not documented.
richardlau commentedon Feb 5, 2021
cc @nodejs/platform-arm Thoughts?
rvagg commentedon Feb 9, 2021
🤷 same as my comment in #31041:
i.e. we haven't even verified that the original problem reported there is something that (a) most users compiling on Raspbian Buster are going to experience and (b) is something they can't easily work around. Or maybe GYP needs to get involved here.
I'd rather be minimal and appreciate the pain reported in this issue, someone just needs to do the legwork of resolving the problem to make sure our binaries can compile with our plain armv7 toolchain but also run on Raspbian Buster. Our Pi cluster still doesn't have Buster in the mix so we can't verify directly with our CI unfortunately. If we can rip out
-latomicwithout just playing wac-a-mole with some other subset of users then I'm +1 to that.viceice commentedon Oct 17, 2025
it seems since v25 it's also required for amd64 and arm64.
https://github.com/containerbase/node-prebuild/actions/runs/18548326782/job/52870522627#step:3:662
targos commentedon Oct 17, 2025
/cc @richardlau I guess that's because of the switch to Clang?
richardlau commentedon Oct 17, 2025
Yes.
FWIW using V8's custom libcxx would avoid it (using the atomics there instead). There is an indication in https://chromium-review.googlesource.com/c/chromium/src/+/5963336 that the V8 maintainers would like to drop support for building without the custom libcxx in the future.
doc: clarify Linux runtime requirements for >=25
doc: clarify Linux runtime requirements for >=25
github-actions commentedon Jun 27, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
alexsch01 commentedon Jun 27, 2026
Keep this opened
Also retitle this issue since it affects all clang node builds (the default since nodejs 25)
sxa commentedon Jun 30, 2026
As per one of the issues linked above (#60484) that scenario seems to be documented for that case now so I don't think this issue needs to be rescoped for that.
If someone wants this fixed for arm32 I would suggest that they create a suitable equivalent PR. Also bear in mind that arm32 is not a release platform as of Node 24.
github-actions commentedon Sep 29, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
alexsch01 commentedon Sep 29, 2026
Mark not stale