Include libatomic1

[GauBen]

Hi!

Since v25, Node requires libatomic1 to run, which is not available in distroless images.

./node: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

My current workaround is adding this line to my Dockerfile:

COPY --from=build /lib/x86_64-linux-gnu/libatomic.so.1 /lib/x86_64-linux-gnu/libatomic.so.1

It seems to be a brittle solution, but the best I could find. Should libatomic1 be included in the cc distroless images?

Thank you for this project

[loosebazooka]

I'm not sure what to do here. I don't want to include this unnecessarily in the other images. Its possible we just put it in the node images starting with 26 (we only do LTS builds). Are you just building node25 on top of the cc image?

[GauBen]

Are you just building node25 on top of the cc image?

Yes, I'm using the single executable application feature of Node (in particular --build-sea added in Node 25.5) to bundle my whole application as a single binary, then copy it to the cc distroless image.

It's ok for my use case to wait for Node 26 and then overwrite the node binary in the adequate distroless image

[loosebazooka]

Ah but you'll still have an unnecessary node install on that image? We can maybe look into adding a nodejs-base image for this usecase. I'm not sure

[polarathene]

A separate stage to install the dep from the equivalent Debian base image and COPY should be fine? For users of the image it won't make any difference on their pull vs distroless having some image variant for this.

I'd probably wait for more demand of such before committing to any new variants.

For reference, here is the upstream issue.

• It's possible that upstream would just fix it by having their CI builds static link libatomic.a instead.
• Otherwise anyone else could technically build Node from source as a workaround to manually static link libatomic, but just copying over the shared library would be far quicker/simpler.

One other option to get a base image similar to Distroless is via Canonical's chisel, but it's not as convenient. With the added verbosity/complexity it requires atm, I assume a custom image via Bazel might not be that much different.

---

My current workaround is adding this line to my Dockerfile:

COPY --from=build /lib/x86_64-linux-gnu/libatomic.so.1 /lib/x86_64-linux-gnu/libatomic.so.1

You're copying a symlink, typically that file is meant to be a symlink that resolves to the full versioned library (libatomic.so.1.2.0 for many years).

Docker may resolve that symlink for the copy operation but in some cases it does not IIRC (might be COPY --link, or was related to before/after BuildKit, I can't quite recall).

EDIT: I was recalling the opposite issue, trying to preserve symlinks when using COPY (one file was a symlink the other was the binary). So you'd potentially encounter that issue too if you did include libatomic.so.1.2.0, losing the libatomic.so.1 symlink. See the linked PR for a solution that recreates the symlink in a distroless environment, but I assume you can get away with just leaving it as you already have it (libatomic.so.1 is the DT_SONAME acquired for adding to Node's DT_NEEDED_).