Docker Alpine executable binary not found even if in PATH
I have an alpine running container which contains some binaries in usr/local/bin When I ls the content of usr/local/bin I got this output :
/usr/local/bin # ls dwg2SVG dwg2dxf dwgadd dwgbmp dwgfilter dwggrep dwglayers dwgread dwgrewrite dwgwrite dxf2dwg dxfwrite Which is what I expected. However if I execute one of these binaries by calling it I got a not found error from the shell :
/usr/local/bin # dwg2dxf sh: dwgread: not found /usr/local/bin # ./dwg2dxf sh: ./dwgread: not found /usr/local/bin # echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin How can I make those binaries callable or «foundable» ? Did I miss something in my Dockerfile build ? I suppose that there is something with the ldconfig command in alpine that went wrong but I’m not sure. EDIT As suggested in one answer here I executed the file command and here is the output :
/usr/local/bin # file dwg2dxf dwgread: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=7835d4a42651a5fb7bdfa2bd8a76e40096bacb07, with debug_info, not stripped Thoses binaries are from the LibreDWG Official repository as well as the first part of my Dockerfile. Here is the complete Dockerfile :
# podman/docker build -t libredwg . ############################ # STEP 1 build package from latest tar.xz ############################ FROM python:3.7.7-buster AS extracting # libxml2-dev is broken so we need to compile it by our own ARG LIBXML2VER=2.9.9 RUN apt-get update && \ apt-get install -y --no-install-recommends autoconf libtool swig texinfo \ build-essential gcc libxml2 python3-libxml2 libpcre2-dev libpcre2-32-0 curl \ libperl-dev libxml2-dev && \ mkdir libxmlInstall && cd libxmlInstall && \ wget ftp://xmlsoft.org/libxml2/libxml2-$LIBXML2VER.tar.gz && \ tar xf libxml2-$LIBXML2VER.tar.gz && \ cd libxml2-$LIBXML2VER/ && \ ./configure && \ make && \ make install && \ cd /libxmlInstall && \ rm -rf gg libxml2-$LIBXML2VER.tar.gz libxml2-$LIBXML2VER WORKDIR /app RUN tarxz=`curl --silent 'https://ftp.gnu.org/gnu/libredwg/?C=M;O=D' | grep '.tar.xz What if you try to execute it with absolute path?: /usr/local/bin/dwg2dxf Also, is that $PATH exported so that dwg2dxf sees it too, as the error is dwgread: not found like dwg2dxf couldn't find dwgread for executing.
@jossefaz : I notice two strange things in your question: First you tag it as bash, but the error message you get does not come from bash. The, you don't test the PATH in connection with the command which you executed. To be on the safe side, I would do a (printenv PATH; ls -l /usr/local/bin/dwg2dxf; dwg2dxf) .
@user1934428 : I updated the question tag. For the second point I'll try and edit ;y question with the outpout. But I think I am close to a workaround by using another base image in my dockerfile.
Can you edit the question to include the Dockerfile directly, not behind a link? Where do the binaries come from? Switching to an Ubuntu base potentially addresses this kind of issue, or it's possible you're missing some shared-library dependencies that need to be installed.
@DavidMaze : thanks for your comment. I've edited my question the entire Dockefile as well as a link to the official repository those binaries came from. Actually I did change the base image an hour ago and it worked. But it's not an ideal solution for me. But since it's working and since it could help other people, I've post this workaround as a response to my own question. If anyone find any improvement to this workaround feel free to post another answer and I could remove mine
6 Answers 6
On Alpine Linux, the not found error is a typical symptom of dynamic link failure. It is indeed a rather confusing error by musl's ldd linker.
Most of the world Linux software is linked against glibc, the GNU libc library (libc provides the standard C library and POSIX API). Most Linux distributions are based on glibc. OTOH, Alpine Linux is based on the musl libc library, which is a minimal implementation and strictly POSIX compliant. Executables built on glibc distributions depend on /lib/x86_64-linux-gnu/libc.so.6 , for example, which is not available on Alpine (unless, they are statically linked).
Except for this dependency, it's important to note that while musl attempts to maintain glibc compatibility to some extent, it is far from being fully compatible, and complex software that's built against glibc won't work with musl-libc, so simply symlinking /lib/ld-musl-x86_64.so.1 to the glibc path isn't likely going to work.
Generally, there are several ways for running glibc binaries on Alpine:
# apk add gcompat apk add libc6-compat Both packages provide a light weight glibc compatibility layer which may be suitable for running simple glibc applications. libc6-compat implements glibc compatibility APIs and provides symlinks to glibc shared libraries such as libm.so , libpthread.so and libcrypt.so . The gcompat package is based on Adelie Linux gcompat project and does the same but provides a single library libgcompat.so . Both libraries install loader stubs. Depdending on the application, one of them may work while the other won't, so it's good to try both.
- Install proper glibc on Alpine, for providing all glibc methods and functionalities. There are glibc builds available for Alpine, which should be installed in the following procedure (example):
# Source: https://github.com/anapsix/docker-alpine-java ENV GLIBC_REPO=https://github.com/sgerrand/alpine-pkg-glibc ENV GLIBC_VERSION=2.30-r0 RUN set -ex && \ apk --update add libstdc++ curl ca-certificates && \ for pkg in glibc-$ glibc-bin-$; \ do curl -sSL $/releases/download/$/$.apk -o /tmp/$.apk; done && \ apk add --allow-untrusted /tmp/*.apk && \ rm -v /tmp/*.apk && \ /usr/glibc-compat/sbin/ldconfig /lib /usr/glibc-compat/lib - Use statically linked executables. Static executables don't carry dynamic dependencies and could run on any Linux.
- Alternatively, the software may be built from source on Alpine.
For LibreDWG, let's first verify the issue:
/usr/local/bin # ./dwg2dxf /bin/sh: ./dwg2dxf: not found /usr/local/bin /usr/local/bin # ldd ./dwg2dxf /lib64/ld-linux-x86-64.so.2 (0x7fd375538000) libredwg.so.0 => /usr/local/lib/libredwg.so.0 (0x7fd3744db000) libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fd375538000) libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fd375538000) Error relocating /usr/local/lib/libredwg.so.0: __strcat_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __snprintf_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __memcpy_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __stpcpy_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __strcpy_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __printf_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __fprintf_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __strncat_chk: symbol not found Error relocating /usr/local/lib/libredwg.so.0: __sprintf_chk: symbol not found Error relocating ./dwg2dxf: __snprintf_chk: symbol not found Error relocating ./dwg2dxf: __printf_chk: symbol not found Error relocating ./dwg2dxf: __fprintf_chk: symbol not found You can see that dwg2dxf depends on several glibc symbols. Now, let's follow option 2 for installing glibc:
/usr/src/app # cd /usr/local/bin /usr/local/bin # ls dwg2SVG dwg2dxf dwgadd dwgbmp dwgfilter dwggrep dwglayers dwgread dwgrewrite dwgwrite dxf2dwg dxfwrite /usr/local/bin # ./dwg2dxf /bin/sh: ./dwg2dxf: not found /usr/local/bin # export GLIBC_REPO=https://github.com/sgerrand/alpine-pkg-glibc && \ > export GLIBC_VERSION=2.30-r0 && \ > apk --update add libstdc++ curl ca-certificates && \ > for pkg in glibc-$ glibc-bin-$; \ > do curl -sSL $/releases/download/$/$.apk -o /tmp/$.apk; done && \ > apk add --allow-untrusted /tmp/*.apk && \ > rm -v /tmp/*.apk && \ > /usr/glibc-compat/sbin/ldconfig /lib /usr/glibc-compat/lib 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 curl (7.74.0-r1) Executing busybox-1.32.1-r3.trigger OK: 629 MiB in 126 packages (1/2) Installing glibc (2.30-r0) (2/2) Installing glibc-bin (2.30-r0) Executing glibc-bin-2.30-r0.trigger /usr/glibc-compat/sbin/ldconfig: /usr/local/lib/libredwg.so.0 is not a symbolic link /usr/glibc-compat/sbin/ldconfig: /usr/glibc-compat/lib/ld-linux-x86-64.so.2 is not a symbolic link OK: 640 MiB in 128 packages removed '/tmp/glibc-2.30-r0.apk' removed '/tmp/glibc-bin-2.30-r0.apk' /usr/glibc-compat/sbin/ldconfig: /usr/glibc-compat/lib/ld-linux-x86-64.so.2 is not a symbolic link /usr/glibc-compat/sbin/ldconfig: /usr/local/lib/libredwg.so.0 is not a symbolic link /usr/local/bin # ./dwg2dxf Usage: dwg2dxf [-v[N]] [--as rNNNN] [-m|--minimal] [-b|--binary] DWGFILES. qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
I have a Rancher Deskop(dockerd) on M1 MacOS and when I am trying to build below dockerfile I am getting an error such as below. Here is the command how I am trying to build the image docker build -t te-grafana-dashboards-toolchain --no-cache . I tried to change the platforms but nonae of them worked for me. I am a bit lost about this platform issue for M1 but any help will be appreciated, What I am doing wrong? What might the root cause of this?
Removing intermediate container 70af516d5d6b ---> a69229847153 Step 5/6 : RUN GO111MODULE="on" go get github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb; ln -s $(go env GOPATH)/bin/jb /usr/bin/jb ---> Running in 13545862fffe qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory Removing intermediate container 13545862fffe FROM --platform=linux/amd64 ubuntu:focal RUN apt update; apt install -y curl jq build-essential python3.8 python3-pip docker-compose jsonnet bison mercurial RUN ln -s /usr/bin/python3.8 /usr/bin/python RUN curl -OL https://golang.org/dl/go1.17.linux-amd64.tar.gz; mkdir /etc/golang; tar -xvzf go1.17.linux-amd64.tar.gz -C /etc/golang; ln -s /etc/golang/go/bin/go /usr/bin/go; rm -f go1.17.linux-amd64.tar.gz RUN GO111MODULE="on" go get github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb; ln -s $(go env GOPATH)/bin/jb /usr/bin/jb WORKDIR /workspace /lib64/ld-linux-x86-64.so.2: No such file or directory error
Background I am using docker to do a school project. Specifically, I pulled an ubuntu image and here is the system config: I then logged into the docker container (ubuntu) and set up elasticsearch. When I try to run
/lib64/ld-linux-x86-64.so.2: No such file or directory Please show the exact steps you are running with a copy and paste from the command line. Include the command run, it's output, and post it as formatted text rather than a screenshot. This should include the steps taken to start ubuntu and install/setup elasticsearch.
4 Answers 4
If you are running this on an M1 macbook, it's possible that you are running a native Arm image of ubuntu, instead of the emulated x86 image. If the elasticsearch distribution you are trying to install is for x86_64, then it attempts to link to the x86-64-native ld.so, which of course isn't present on different platforms.
Either install the package for the arm platform specifically if they provide one, or - more likely - run docker explicitly as the emulated x86_64 platform:
docker run --platform linux/x86_64
many hours of searching, and finally found this, it was the missing piece of the puzzle. My use case was a bit different, but ultimately same root cause.
thank you so much, I've encountered the same problem on M1 with docker build command. docker build --platform linux/x86_64 helped!