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

Library used on Linux image not found on M1 ARM64 image #3239

Closed
juliencharrel opened this issue Feb 26, 2021 · 17 comments
Closed

Library used on Linux image not found on M1 ARM64 image #3239

juliencharrel opened this issue Feb 26, 2021 · 17 comments

Comments

@juliencharrel
Copy link

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

@nschonni nschonni transferred this issue from nodejs/docker-node Feb 26, 2021
@yosifkit
Copy link

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
Copy link
Author

Worked like a charm, thanks!

@jstapelfeldt
Copy link

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
Copy link
Author

juliencharrel commented May 5, 2021

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

@nigamzoman
Copy link

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
Copy link

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
Copy link

zisko commented Jan 7, 2022

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
Copy link

gubatron commented Jan 7, 2022

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
Copy link

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

@anna-hope
Copy link

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

@stav-hacohen
Copy link

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
Copy link

ehubbell commented Feb 9, 2022

@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.

CleanShot 2022-02-09 at 15 25 34

@trozdol
Copy link

trozdol commented Feb 10, 2022

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
Copy link

stav-hacohen commented Feb 15, 2022 via email

@olzhasar
Copy link

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  

PikachuEXE added a commit to PikachuEXE/ibc-rs that referenced this issue Jun 11, 2022
Otherwise library not found error will be encountered
Ref: nodejs/help#3239
adizere pushed a commit to informalsystems/hermes that referenced this issue Jun 13, 2022
Otherwise library not found error will be encountered
Ref: nodejs/help#3239
seunlanlege pushed a commit to ComposableFi/ibc-rs that referenced this issue Jun 20, 2022
* Add codespace information in unknown SDK error (informalsystems#2268)

* ICS20 API improvements (informalsystems#2280)

* Remove `Debug` and `'static` requirements on Module trait

* Manually implement Debug for `MockRouter`

* Remove `Ics20Reader` supertrait `PortReader`

* Use primitive_types::U256 instead of uint::construct_uint!()

* Impl serde for Amount

* Add .changelog entries

* Fix relayer Dockerfile for M1 Mac (informalsystems#2286)

Otherwise library not found error will be encountered
Ref: nodejs/help#3239

* Bump uuid from 1.1.1 to 1.1.2 (informalsystems#2289)

Bumps [uuid](https://github.com/uuid-rs/uuid) from 1.1.1 to 1.1.2.
- [Release notes](https://github.com/uuid-rs/uuid/releases)
- [Commits](uuid-rs/uuid@1.1.1...1.1.2)

---
updated-dependencies:
- dependency-name: uuid
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Bump hdpath from 0.6.0 to 0.6.1 (informalsystems#2292)

Bumps [hdpath](https://github.com/emeraldpay/hdpath-rs) from 0.6.0 to 0.6.1.
- [Release notes](https://github.com/emeraldpay/hdpath-rs/releases)
- [Commits](https://github.com/emeraldpay/hdpath-rs/commits)

---
updated-dependencies:
- dependency-name: hdpath
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Bump clap from 3.1.18 to 3.2.1 (informalsystems#2291)

* Bump semver from 1.0.9 to 1.0.10 (informalsystems#2295)

* Bump http from 0.2.7 to 0.2.8 (informalsystems#2296)

* Bump tracing from 0.1.34 to 0.1.35 (informalsystems#2290)

* Hs/2210 - Fixed the variable TM to point to GAIAD_BINARY (informalsystems#2297)

* Fixed variable TM

* change log entry and lib-gm version updated to v0.1.3

Co-authored-by: Harveen Singh <harveen@informal.systems>

* Bump clap_complete from 3.1.4 to 3.2.1 (informalsystems#2288)

* Bump clap_complete from 3.1.4 to 3.2.1

Bumps [clap_complete](https://github.com/clap-rs/clap) from 3.1.4 to 3.2.1.
- [Release notes](https://github.com/clap-rs/clap/releases)
- [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md)
- [Commits](clap-rs/clap@clap_complete-v3.1.4...clap_complete-v3.2.1)

---
updated-dependencies:
- dependency-name: clap_complete
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

* Bump clap dependency to 3.2.4

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Mikhail Zabaluev <mikhail@informal.systems>

* Fix recv packet handler incorrectly using dest port/chan to get receipt/next_seq_recv (informalsystems#2294)

* Use packet destination port/channel in recv_packet handler where appropriate

* Add .changelog entry

* Address review feedback

* Use enum for recv-packet results

* Improve RecvPacketResult

* Ignore acc seq mismath when expected < got (informalsystems#2298)

* Ignore acc seq mismath when expected < got

* Address review comments

* Changelog entry

* Add support for fetching & parsing the Tendermint version of a chain (informalsystems#2302)

* Fix for informalsystems#2301

* changelog

* changelog broken link

* KV pairs in log h/t Mikhail

* update dependencies to master branch

* update tendermint dependency

Co-authored-by: Soares Chen <soares.chen@maybevoid.com>
Co-authored-by: Shoaib Ahmed <sufialhussaini@gmail.com>
Co-authored-by: PikachuEXE <pikachuexe@gmail.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: harveenSingh <harveen.s@hotmail.com>
Co-authored-by: Harveen Singh <harveen@informal.systems>
Co-authored-by: Mikhail Zabaluev <mikhail@informal.systems>
Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-authored-by: Adi Seredinschi <adi@informal.systems>
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this issue Sep 13, 2022
Otherwise library not found error will be encountered
Ref: nodejs/help#3239
@sebastiendan
Copy link

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
Copy link

yosifkit commented Jun 7, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

16 participants