iperf3 segfault ld-musl-x86_64.so on Alpine Linux container about iperf

[davidBar-On]

I built and run iperf3 under Alpine container, when Docker is running under Windows 11 / WSL2 (Ubuntu Linux). The command run o.k. The Dockerfile I used to build the container is:

FROM alpine:latest
RUN apk update && apk upgrade && apk add openssl ca-certificates
RUN apk --no-cache --virtual build-dep add g++ gcc openssl-dev make git automake autoconf

RUN git clone https://github.com/esnet/iperf.git --branch master

RUN cd iperf && ./configure && \
    make install && \
    apk del build-dep automake autoconf && \
    rm -rf /iperf3

The container build command: docker build -t alpine-sh Dockerfile.

The system/iperf3 info:

docker run --rm -ti alpine-sh cat /etc/alpine-release
3.19.1

docker run --rm -ti alpine-sh uname -a
Linux 5f7c8ecfcbda 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 Linux

docker run --rm -ti alpine-sh /usr/local/bin/iperf3 -v
iperf 3.16+ (cJSON 1.7.15)
Linux 509f1cff6ea4 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64
Optional features available: CPU affinity setting, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication, bind to device, support IPv4 don't fragment, POSIX threads

Did you use similar steps to build and run iperf3 in the container? If not, how did you build iperf3? If yes, the problem may be related to platform you are using or the Talos Linux. Is there a way that you can run iperf3 under GDB (or other debugger), so it will be possible to identify were the fault happens? (If a core dump is generated, then it may also be analyzed.)