Library used on Linux image not found on M1 ARM64 image

[juliencharrel]

Environment

• Platform: Mac M1 ARM
• Docker Version: 20.10.3, build 48d30b5
• Node.js Version: v15.5.1
• Image Tag: FROM node:15 (not usre exactly which image is then pulled on Docker preview M1)

Expected Behavior

I am using a built with dependencies Rust binary that works perfectly on images on x86 architecture with the exact same parameters. When launching that binary on the same node:15 image but for Macbook M1, I should get it to work the same way.

Current Behavior

When trying to run my binary in my docker node:15 image on MacbookM1, I get the following error:

qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

Possible Solution

I have no idea, but the lib in question clearly is not here on node:15 ARM64, but is present on a x86_64 node:15 image

[yosifkit]

The Rust binary you have was compiled for an amd64 (x86_64) architecture and needs the linked library. The image you are running on the Mac M1 ARM is likely the arm64v8 image and so doesn't have libraries for amd64. Since Docker for Mac sets up qemu emulation, you can likely use the amd64 image by adding the --platform flag on docker pull and docker run.

[juliencharrel]

Worked like a charm, thanks!

[jstapelfeldt]

The Rust binary you have was compiled for an amd64 (x86_64) architecture and needs the linked library. The image you are running on the Mac M1 ARM is likely the arm64v8 image and so doesn't have libraries for amd64. Since Docker for Mac sets up qemu emulation, you can likely use the amd64 image by adding the --platform flag on docker pull and docker run.

I'm running automatic built in Visual Studio via .yml file. How and where do I include the --platform flag for Mac M1 ARM specifically?

[juliencharrel]

In your Dockerfile, right after the image name, for example:
FROM node:14 --platform=linux/amd64

[nigamzoman]

Thanks for the solution!
Looked up docker reference here https://docs.docker.com/engine/reference/builder/.
The correct to specify the platform flag is FROM --platform=linux/amd64 node:14

[xboxmachine]

The Rust binary you have was compiled for an amd64 (x86_64) architecture and needs the linked library. The image you are running on the Mac M1 ARM is likely the arm64v8 image and so doesn't have libraries for amd64. Since Docker for Mac sets up qemu emulation, you can likely use the amd64 image by adding the --platform flag on docker pull and docker run.

Hi, can you give a example? in the file..

[zisko]

Here's mine for a solana dapp:

This was super helpful thanks all!.

FROM --platform=linux/amd64 ubuntu:latest


RUN apt-get update
RUN apt-get update && apt-get upgrade && apt-get install -y pkg-config build-essential libudev-dev
RUN apt-get -y install curl gnupg
RUN apt-get -y install nodejs
RUN npm install -g yarn
RUN npm i -g @project-serum/anchor-cli

CMD ["solana-install", "anchor-cli", "pkg-config"] 

[gubatron]

2 days wasted until I found this thread, this was super helpful for me too, thank you!

FROM --platform=linux/amd64 ubuntu:18.04

Cheers from the jlibtorrent project, millions of Android and Linux users thank you.

[vysecurity]

--plathform=linux/amd64 doesn't appear to work here on a M1 MacBook. Any idea?

[anna-hope]

@vysecurity >--plathform=linux/amd64
you made a typo in --platform, could that be why?

[stav-hacohen]

docker-compose doesn't support --platform flag.
I've tried to add it to my docker-compose.yaml but still got the error.
Any ideas?

docker-compose.yaml -
service_x:
platform: linux/amd64

[ehubbell]

@stav-hacohen that's odd. The following worked for me:

services
    server:
    image: ubuntu:18.04
    container_name: 'cs-server-server'
    platform: linux/amd64
    build: .
    volumes:
      - type: bind
        source: ${DOCKER_PROJECT_PATH}
        target: ${DOCKER_TARGET_PATH}
    ports:
      - "9339:9339"
      - "9229:9229"
      - "8080:8080"

When I added as an ARG to my Dockerfile it didn't register on the container above. But when I added it to my docker-compose (like the above) all is well.

To check whether it's working you can ssh into your container and run uname -m (should spit out x86_64) or check yoru docker desktop for the AMD64 flag per the image below.

[trozdol]

I don't know if this will help anyone but if I believe I've had the issue where docker will prefer an image that exists locally over a specific platform that does not exist on your system. I've found it helpful to prune images from my system first then bring up a docker compose project and see if that makes a difference. It should have to download all of the images from the registry and will try to find the specific platform if it exists.

[stav-hacohen]

Hi, Thanks for this info. Adding "platform: linux/amd64" to docker-compose.yaml did the trick. Best regards, Stav.

…

On Thu, Feb 10, 2022 at 12:26 AM Eric Hubbell ***@***.***> wrote: @stav-hacohen <https://github.com/stav-hacohen> that's odd. The following worked for me: services server: image: ubuntu:18.04 container_name: 'cs-server-server' platform: linux/amd64 build: . volumes: - type: bind source: ${DOCKER_PROJECT_PATH} target: ${DOCKER_TARGET_PATH} ports: - "9339:9339" - "9229:9229" - "8080:8080" When I added as an ARG to my Dockerfile it didn't register on the container above. But when I added it to my docker-compose (like the above) all is well. To check whether it's working you can ssh into your container and run uname -m (should spit out x86_64) or check yoru docker desktop for the AMD64 flag per the image below. [image: CleanShot 2022-02-09 at 15 25 34] <https://user-images.githubusercontent.com/4422450/153300636-9f9f5320-7460-4cf3-a1d6-e3133a0fb453.png> — Reply to this email directly, view it on GitHub <#3239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWMGH63VUP63J7ZZ4Y7PJUTU2LSZFANCNFSM4YI53WMQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[olzhasar]

In case you are using docker-compose, you can specify the platform like this:

services:  
  frontend:  
    platform: linux/amd64
    build: frontend  
    ports:
      - 80:80  
    depends_on:
      - backend  
  backend:  
    platform: linux/amd64
    build: backend  

[sebastiendan]

I understand that thanks to qemu macs with Apple Silicon chips can run amd64 images successfully. But shouldn't there be another approach where one can actually build arm64 images that do work? It seems everyone is fine with working with emulation, but I've read here and there that this can become a problem in some situations (also, running my docker-compose stack locally on an M1 mac, I get warnings I would ideally like to see gone).

[yosifkit]

I understand that thanks to qemu macs with Apple Silicon chips can run amd64 images successfully. But shouldn't there be another approach where one can actually build arm64 images that do work? It seems everyone is fine with working with emulation, but I've read here and there that this can become a problem in some situations (also, running my docker-compose stack locally on an M1 mac, I get warnings I would ideally like to see gone).

As long as the tag of each image (like node:20-bullseye) that you are using are an image index that has amd64 and arm64 versions, then --platform and emulation should be unnecessary. Problems arise when using pre-compiled binaries (copied in or downloaded during build) that are architecture specific (like the initial issue here). The multiarchitecture awareness needs to be addressed in the Dockerfile, like downloading a binary for the userspace architecture; see one of the golang Dockerfiles as an example.

As far as building your own multiplatform images (i.e. multiple platform specific images under a single tag via an image index), there are resources like https://docs.docker.com/build/building/multi-platform/ that can be helpful. I try to build each architecture on a native CPU rather than relying on emulation for both speed and reliability.