Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image does not build on other architectures than x86_64 #4

Open
bakousylla opened this issue Nov 9, 2021 · 16 comments
Open

Image does not build on other architectures than x86_64 #4

bakousylla opened this issue Nov 9, 2021 · 16 comments
Labels
enhancement New feature or request help wanted Extra attention is needed
Milestone

Comments

@bakousylla
Copy link

Hello,

I get this error /usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory if I try to generate an image with your dockerfile, do you have any idea what the problem might be ?
Thanks for your help

@bentolor
Copy link
Owner

bentolor commented Nov 9, 2021

@bakousylla Which command triggers this error?

@bentolor bentolor added the bug Something isn't working label Nov 9, 2021
bentolor added a commit that referenced this issue Nov 9, 2021
@bentolor
Copy link
Owner

bentolor commented Nov 9, 2021

@bakousylla Still, please provide me the aws command which triggered this error.

Anyway: I just uploaded a new version of the tool including the mentioned library. Can you check if this resolves your issue?

@bentolor bentolor added the question Further information is requested label Nov 9, 2021
@bakousylla
Copy link
Author

I'have the same issue /usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory after pulling your modif

@bentolor
Copy link
Owner

bentolor commented Nov 9, 2021

@bakousylla So please advise: Which cmmand triggers this error?

@bentolor bentolor changed the title error while loading shared libraries /usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory Nov 9, 2021
@bakousylla
Copy link
Author

bakousylla commented Nov 9, 2021

when I just try to build image


(base) ➜  docker-dind-awscli git:(master) docker build -t test:latest "."
Sending build context to Docker daemon  83.46kB
Step 1/4 : FROM docker
 ---> 4844bf2dfb03
Step 2/4 : ENV GLIBC_VER=2.34-r0
 ---> Using cache
 ---> 74a32c499b12
Step 3/4 : RUN apk --update-cache add         binutils         curl         groff         bash         zlib     && sed -i 's/ash/bash/g' /etc/passwd     && curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub     && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk     && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk     && apk del libc6-compat     && apk add         glibc-${GLIBC_VER}.apk         glibc-bin-${GLIBC_VER}.apk     && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip     && unzip -q awscliv2.zip     && aws/install     && rm -rf         awscliv2.zip         aws         /usr/local/aws-cli/v2/*/dist/aws_completer         /usr/local/aws-cli/v2/*/dist/awscli/data/ac.index         /usr/local/aws-cli/v2/*/dist/awscli/examples     && apk --no-cache del         binutils         curl     && rm glibc-${GLIBC_VER}.apk     && rm glibc-bin-${GLIBC_VER}.apk     && rm -rf /var/cache/apk/*     && docker --version     && aws --version
 ---> Running in 8f977920758b
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/aarch64/APKINDEX.tar.gz
(1/10) Installing readline (8.1.0-r0)
(2/10) Installing bash (5.1.4-r0)
Executing bash-5.1.4-r0.post-install
(3/10) Installing libgcc (10.3.1_git20210424-r2)
(4/10) Installing libstdc++ (10.3.1_git20210424-r2)
(5/10) Installing binutils (2.35.2-r2)
(6/10) Installing brotli-libs (1.0.9-r5)
(7/10) Installing nghttp2-libs (1.43.0-r0)
(8/10) Installing libcurl (7.79.1-r0)
(9/10) Installing curl (7.79.1-r0)
(10/10) Installing groff (1.22.4-r1)
Executing busybox-1.33.1-r3.trigger
OK: 34 MiB in 32 packages
(1/1) Purging libc6-compat (1.2.2-r3)
OK: 34 MiB in 31 packages
(1/2) Installing glibc (2.34-r0)
(2/2) Installing glibc-bin (2.34-r0)
Executing glibc-bin-2.34-r0.trigger
/usr/glibc-compat/sbin/ldconfig: /usr/lib/libtls.so.2.0.3 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libcrypto.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libssl.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libtls.so.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libbrotlienc.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libbrotlidec.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libbrotlicommon.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libreadline.so.8.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libbrotlidec.so.1.0.9 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libctf.so.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libopcodes-2.35.2.so is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libctf-nobfd.so.0.0.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libbfd-2.35.2.so is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libnghttp2.so.14 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libnghttp2.so.14.20.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libstdc++.so.6.0.28 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libbrotlicommon.so.1.0.9 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libctf-nobfd.so.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libstdc++.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libcurl.so.4 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libbrotlienc.so.1.0.9 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libreadline.so.8 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libgcc_s.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libctf.so.0.0.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libcurl.so.4.7.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libpanelw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libpanelw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libformw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libncursesw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libedit.so.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libformw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libmenuw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libncursesw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libedit.so.0.0.64 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libmenuw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libz.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libcrypto.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libssl.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libz.so.1.2.11 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libapk.so.3.12.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/ld-musl-aarch64.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libc.musl-aarch64.so.1 is for unknown machine 183.

OK: 41 MiB in 33 packages
/aws/dist/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
You can now run: /usr/local/bin/aws --version
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/aarch64/APKINDEX.tar.gz
(1/5) Purging binutils (2.35.2-r2)
(2/5) Purging curl (7.79.1-r0)
(3/5) Purging libcurl (7.79.1-r0)
(4/5) Purging brotli-libs (1.0.9-r5)
(5/5) Purging nghttp2-libs (1.43.0-r0)
Executing busybox-1.33.1-r3.trigger
Executing glibc-bin-2.34-r0.trigger
/usr/glibc-compat/sbin/ldconfig: /usr/lib/libtls.so.2.0.3 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libcrypto.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libssl.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libtls.so.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libreadline.so.8.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libstdc++.so.6.0.28 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libstdc++.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libreadline.so.8 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libgcc_s.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libpanelw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libpanelw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libformw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libncursesw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libedit.so.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libformw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libmenuw.so.6 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libncursesw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libedit.so.0.0.64 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /usr/lib/libmenuw.so.6.2 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libz.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libcrypto.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libssl.so.1.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libz.so.1.2.11 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libapk.so.3.12.0 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/ld-musl-aarch64.so.1 is for unknown machine 183.

/usr/glibc-compat/sbin/ldconfig: /lib/libc.musl-aarch64.so.1 is for unknown machine 183.

OK: 30 MiB in 28 packages
Docker version 20.10.10, build b485636
/usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
The command '/bin/sh -c apk --update-cache add         binutils         curl         groff         bash         zlib     && sed -i 's/ash/bash/g' /etc/passwd     && curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub     && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk     && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk     && apk del libc6-compat     && apk add         glibc-${GLIBC_VER}.apk         glibc-bin-${GLIBC_VER}.apk     && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip     && unzip -q awscliv2.zip     && aws/install     && rm -rf         awscliv2.zip         aws         /usr/local/aws-cli/v2/*/dist/aws_completer         /usr/local/aws-cli/v2/*/dist/awscli/data/ac.index         /usr/local/aws-cli/v2/*/dist/awscli/examples     && apk --no-cache del         binutils         curl     && rm glibc-${GLIBC_VER}.apk     && rm glibc-bin-${GLIBC_VER}.apk     && rm -rf /var/cache/apk/*     && docker --version     && aws --version' returned a non-zero code: 127

@bentolor
Copy link
Owner

bentolor commented Nov 9, 2021

It seems that you are trying to build this image on aarch64 architecture, right?

Your main issue is, that currently the Dockerfile downloads & installs the x86_64 build of the glibc library set.

I found an open issue upstream there asking for an arm port: sgerrand/alpine-pkg-glibc#126

Maybe this approach to build a container without GLIBC works on aarm64? : aws/aws-cli#4685 (comment)

@bentolor bentolor changed the title /usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory Image does not build on other architectures than x86_64 Nov 9, 2021
@bentolor bentolor added enhancement New feature or request and removed bug Something isn't working question Further information is requested labels Nov 9, 2021
@bakousylla
Copy link
Author

you are right, I have the arm root:xnu-7195.141.6~3/RELEASE_ARM64_T8101 arm64, I'll try your solution without GLIBC, thanks a lot

@Ic3w0lf
Copy link

Ic3w0lf commented Nov 18, 2021

I think I got it working with GLIBC on ARM by installing GLIBC from SatoshiPortal, which also provides them for aarch64. Afterwards you also have to install the aarch64 version of the awscli. Here is my Dockerfile for reference:

FROM alpine:3.14

ARG AWS_CLI_VERSION=2.3.6

ARG GLIBC_ARCH=aarch64
ARG GLIBC_VERSION=2.33-r0

#
# System tools and dependencies
RUN set -e \
    && apk add --no-cache \
        binutils \
        curl \
        groff \
    && rm -rf /var/cache/apk/* /tmp/*

#
# Install glibc (required for awscli)
RUN set -e \
    && cd /tmp \
    && GLIBC_KEY="https://github.com/SatoshiPortal/alpine-pkg-glibc/releases/download/${GLIBC_VERSION}/[email protected]" \
    && GLIBC_URL='https://github.com/SatoshiPortal/alpine-pkg-glibc/releases/download' \
    && curl -sL ${GLIBC_KEY} -o /etc/apk/keys/[email protected] \
    && curl -sLO ${GLIBC_URL}/${GLIBC_VERSION}/glibc-${GLIBC_VERSION}-${GLIBC_ARCH}.apk -o glibc-${GLIBC_VERSION}.apk \
    && curl -sLO ${GLIBC_URL}/${GLIBC_VERSION}/glibc-bin-${GLIBC_VERSION}-${GLIBC_ARCH}.apk -o glibc-bin-${GLIBC_VERSION}.apk \
    && curl -sLO ${GLIBC_URL}/${GLIBC_VERSION}/glibc-i18n-${GLIBC_VERSION}-${GLIBC_ARCH}.apk -o glibc-i18n-${GLIBC_VERSION}.apk \
    && apk add --update --no-cache *.apk; \
        /usr/glibc-compat/bin/localedef -i en_US -f UTF-8 en_US.UTF-8 \
    && apk del --purge glibc-i18n \
    && rm -rf /var/cache/apk/* /tmp/*

#
# Install awscli2
RUN set -e \
    && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-${GLIBC_ARCH}-${AWS_CLI_VERSION}.zip -o awscliv2.zip \
    && unzip -q awscliv2.zip \
    && aws/install; \
        aws --version \
    && rm -f awscliv2.zip

WORKDIR /app
CMD ["/bin/sh"]

You can switch between aarch64 and amd64 by changing the BUILD_ARG to x86_64. Hoping this helps someone!

@bentolor
Copy link
Owner

@Ic3w0lf Awesome. Thanks for you contribution.

If I find a feasible easy way to crosscompile for other architectures I might adopt your example into my build and start publishing for additional architectures, too.

Just our of curiosity: What is you motivation for a aarch64? Raspberry Pi? Apple M1? Any new server plattform?

@Ic3w0lf
Copy link

Ic3w0lf commented Nov 18, 2021

@bentolor Super glad this is helpful :) My main motivation is Apple M1 in this case. I don't have any Apple Silicon myself, but wanted to provide this container as multiarch build for my colleagues who often go with M1 (especially in the future).

I couldn't really test in-depth if this works but asked a friend who is on M1 if he could quickly run aws --version in this container and he reported it works! 🤞

Looking forward to see you try out other architectures as well! What architectures do you have in mind?

@bentolor
Copy link
Owner

@Ic3w0lf Thanks for your insights.

To be honest: You issue showed me my ignorance regarding alternative platforms. Till now in IT we just developed for x86 and that was it. The latest moves in the market (ARM-based M1 & server hardware) and given that the list of supported architecture has grown quite a lot for popular open-source projects, I wondered which other architectures I should keep in mind for Docker workloads.

Looking on the linked list I think windows-amd64 might be potentially relevant, too.

But it seems we are both driven by the same interest in being prepared for upcoming trends. I just resurrected my old Raspberry Pi 3B and installed an aarch64 version of ubuntu on it so I can test your Dockerfile.

@Ic3w0lf
Copy link

Ic3w0lf commented Nov 18, 2021

@bentolor Thank you for insights as well!

I agree with you. Until now it has pretty much been amd64 or nothing but I am really glad that Apple is heating up the architecture debate. Even though I am not an Apple fan I love the competition they bring into the game :)

And please let me know if awscli works as expected on a native arm system once you get to it!

Cheers and have a great evening!

@david-AH
Copy link

Hitting the same error. Haven't yet attempted the workaround, but wondering if there were any updates on a cross compiled option?

@bentolor
Copy link
Owner

@david-AH just for my "census": Which architectures are you missing? Unfortunately this needs to be tackled individually per plattform right now.

@david-AH
Copy link

Apple M1 -> arm64

@bentolor
Copy link
Owner

Okay, after I realized cross-building is quite simple usine QEmu, I did a first run, but failed to succeed. You can see my efforts at https://github.com/bentolor/docker-dind-awscli/tree/experimental/aarch64 and there is a BUILD.md describing what needs to be done to get the build running.

Unfortunately the build fails with errors like

/usr/glibc-compat/sbin/ldconfig: /usr/glibc-compat/lib/ld-linux-aarch64.so.1 is not a symbolic link

OK: 32 MiB in 28 packages
Docker version 20.10.21, build baeda1f
/usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

Not sure what's the culprit here. I also had to downgrade the glibc version as the source does not provide newer builds.

@bentolor bentolor added the help wanted Extra attention is needed label Nov 16, 2023
@bentolor bentolor added this to the Backlog milestone Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants