armv7l package requires libatomic.so.1 since 12.16.0 but not documented

[deepak1556]

• 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]

[deepak1556]

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.

[mscdex]

I'm guessing the build environment used for armv7 releases changed.

/cc @nodejs/build

[richardlau]

It looks like #31041 would be the most likely change.

[deepak1556]

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]

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.

cc @nodejs/platform-arm Thoughts?

[rvagg]

🤷 same as my comment in #31041:

we're neither testing Buster, nor GCC 8 yet, so I suppose there's something in this combination that we're not getting.

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 -latomic without just playing wac-a-mole with some other subset of users then I'm +1 to that.

[viceice]

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]

/cc @richardlau I guess that's because of the switch to Clang?

[richardlau]

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.