error while loading shared libraries: libatomic.so.1

[zhaohuabing]

docker run envoyproxy/nighthawk-dev:latest nighthawk_client       
nighthawk_client: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

It looks like this issue was introduced in #1309. @eric846

[eric846]

Sorry about that. The -lrt -latomic was needed for the CI build to work after updating to the latest Envoy. But these flags were actually not needed to build on my local Debian.

I would like to find a way to enable those flags only when building on CI, so we could remove the flags by default, including when building for Docker.

There are signs that these libraries are complicated, if you search for "In particular" here: envoyproxy/envoy#1069

[eric846]

Meanwhile if it's possible to edit the docker file locally before you run it, you might be able to fix it with:

apk add libatomic

[zirain]

@eric846 there's no image base on tag, we can send a workaround fix with apk add libatomic in Dockerfile for short term?

[eric846]

I see what you mean about the tags on docker hub. The most recent tag is 3 years old.

Unfortunately I tried the apk add libatomic workaround locally and it doesn't seem to work:

sudo docker run --rm -it envoyproxy/nighthawk-dev:latest ash

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

/ # apk add libatomic
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/APKINDEX.tar.gz
(1/1) Installing libatomic (10.2.1_pre1-r3)
Executing glibc-bin-2.33-r0.trigger
/usr/glibc-compat/sbin/ldconfig: /usr/glibc-compat/lib/ld-linux-x86-64.so.2 is not a symbolic link

OK: 17 MiB in 18 packages

/ # nighthawk_client
nighthawk_client: /usr/lib/libatomic.so.1: no version information available (required by nighthawk_client)
Inconsistency detected by ld.so: dl-lookup.c: 105: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
/ # 

Please let me know if you find a workaround with the image. We will keep trying to find a solution.

[zhaohuabing]

@eric846 I'm not familiar with the bazel build, but would static link be an option to solve this?

[eric846]

That is a great idea, and it appears to work. Created #1314

[zirain]

I can workaround with following dockerfile:

FROM envoyproxy/nighthawk-dev:latest AS source

FROM ubuntu:22.04@sha256:0e5e4a57c2499249aafc3b40fcd541e9a456aab7296681a3994d631587203f97

RUN apt-get update && apt-get install \
        autoconf \
        automake \
        cmake \
        curl \
        libtool \
        make \
        ninja-build \
        patch \
        python3-pip \
        unzip \
        virtualenv -y

COPY --from=source /usr/local/bin/nighthawk_client /usr/local/bin/nighthawk_client
COPY --from=source /usr/local/bin/nighthawk_test_server /usr/local/bin/nighthawk_test_server
COPY --from=source /usr/local/bin/nighthawk_output_transform /usr/local/bin/nighthawk_output_transform
COPY --from=source /usr/local/bin/nighthawk_service /usr/local/bin/nighthawk_service
COPY --from=source /usr/local/bin/nighthawk_adaptive_load_client /usr/local/bin/nighthawk_adaptive_load_client
COPY --from=source /etc/envoy/envoy.yaml /etc/envoy/envoy.yaml

# Ports for nighthawk_test_server, see default-config.yaml
EXPOSE 10001
EXPOSE 10080
# The default port for nighthawk_service
EXPOSE 8443

CMD ["-c", "/etc/envoy/envoy.yaml"]

[eric846]

Thank you @zirain for validating Ubuntu. #1315 will migrate the image to Ubuntu.

[eric846]

The new image is live. Let us know if it works!

docker rmi envoyproxy/nighthawk-dev:latest

docker run envoyproxy/nighthawk-dev:latest nighthawk_client