SDK for aarch64

[timohanke]

We need the SDK for users of M1-based Macs.

[ghost]

can we just expand that aarch64?

[devidw]

Tried to add aarch64 to the installation script where the CPU type is detected, so it is processed as _cputype=x86_64.

On alpine base image with docker, the installation completes, but execution fails with:

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

[nmattia]

Would be really, really nice to be able to build on aarch64. As far as I can tell the only issue currently is that we require released assets for the build. Looks like this is just a matter of niv adding some the correct download URLs to sources.json and pinging whomever is responsible for https://download.dfinity.systems/blessed/ic/<rev>/sdk-release/x86_64-darwin/<asset> to populate it. Who do we reach out to to get some aarch64 builds of the following binaries?

"ic-ref" "icx-proxy" "ic-starter" "motoko" "replica" "canister-sandbox" "sandbox-launcher"

[sesi200]

x86_64-darwin has been working for quite a while now. Re-naming this to refer to aarch64

[sesi200]

Merging duplicate feature request from @domwoe:

@mbeekman from ICPipline wanted to run dfx (0.11.0) in an Ubuntu Docker environment on an M1 (or M2) Mac. However, there's no release of dfx for this platform

dfinity-sdk: unknown CPU type: aarch64

A few months earlier I tried to a similar setup for my canister monitoring example application. I got this to work then (dfx 0.10.0) by running Docker with emulation

DOCKER_DEFAULT_PLATFORM=linux/amd64

With this setup, dfx could be installed but dfx start is extremely slow. However, with newer versions it seems, there's some internal timeout which kills the replica. See the following log:

canister-monitoring-canister-1  | Running dfx start for version 0.12.0-beta.3
canister-monitoring-canister-1  | Using project-specific network 'local' defined in /canister/dfx.json
canister-monitoring-canister-1  | WARN: Project-specific networks are deprecated and will be removed after February 2023.
canister-monitoring-canister-1  | Local server configuration:
canister-monitoring-canister-1  |   bind address: 0.0.0.0:8000 (default: 127.0.0.1:8000)
canister-monitoring-canister-1  |   bitcoin: disabled
canister-monitoring-canister-1  |   canister http: enabled
canister-monitoring-canister-1  |     log level: Error
canister-monitoring-canister-1  |   replica:
canister-monitoring-canister-1  |     subnet type: Application
canister-monitoring-canister-1  |     log level: Error
canister-monitoring-canister-1  |   data directory: /canister/.dfx/network/local
canister-monitoring-canister-1  |   scope: project
canister-monitoring-canister-1  | 
canister-monitoring-canister-1  | Starting canister http adapter...
canister-monitoring-canister-1  | canister http adapter ready
canister-monitoring-canister-1  | Starting replica...
canister-monitoring-canister-1  | Error: An error happened during communication with the replica: error sending request for url (http://0.0.0.0:8000/api/v2/status): error trying to connect: tcp connect error: Connection refused (os error 111)
canister-monitoring-canister-1  | thread 'replica-actor' panicked at 'called `Result::unwrap()` on an `Err` value: Cannot start the replica: Timeout', src/dfx/src/actors/replica.rs:376:78
canister-monitoring-canister-1  | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
canister-monitoring-canister-1  | qemu: uncaught target signal 6 (Aborted) - core dumped
canister-monitoring-canister-1  | /root/.cache/dfinity/versions/0.12.0-beta.3/sandbox_launcher: error while loading shared libraries: libunwind.so.8: cannot open shared object file: No such file or directory
canister-monitoring-canister-1  | thread '<unnamed>' panicked at 'Error from launcher process, pid 114 exited with status code: 127', canister_sandbox/replica_controller/src/sandboxed_execution_controller.rs:1305:23
canister-monitoring-canister-1  | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
canister-monitoring-canister-1  | qemu: uncaught target signal 6 (Aborted) - core dumped

Can we provide a release of dfx for aarch64 or at least provide some documentation to build a release for this platform?

[domwoe]

Sorry, should have checked.

[paulyoung]

I’m on an M1 Mac and the existing macOS releases work for me.

[domwoe]

It's about running in a Linux Docker environment on a M1 Mac.

[mbeekman]

Thanks everyone … let me know if I can help …

[domwoe]

@mbeekman Did you ever get it to work using nix builds?

[mbeekman]

I didn't do it, but Paul ( @ninegua ) did :) ...
https://forum.dfinity.org/t/introducing-ic-nix-a-ready-made-cross-platform-and-bleeding-edge-dev-environment/13107
https://github.com/ninegua/ic-nix

Thanks Paul ... never circled back on the forum, got sidetracked ...

@ocluf - hope this helps your project ... good to see you still out in the IC mix :)

[ocluf]

Hey @mbeekman,

I didn't really have any personal issue where I needed this, but I made a rust starter repo and I thought it would be a much better dev experience for newcomers if they could use the build in support in vscode for devcontainers.

With this I could make an aarch64 build of the sdk and make an image which includes it, but it would go out of sync quickly with every SDK release unless I kept it up to date. It would be much more preferable if the foundation could include it in their build process and sdk download script.

Sidenote: docker recently released a beta for running the docker vm in rosetta mode instead of using QEMU for AMD images. Sadly I got timeout errors running dfx start

[ocluf]

Wanted to leave a comment here in support of this effort. Using vscode devcontainers the entire quickstart for all platforms could be replaced with:

• install docker if you don't have it
• open the repository in vscode and click the "open in devcontainer" popup that show up.

We recommend people to create docker containers anyways so you get a consistent wasm hash. You would get that part for free as well.

[bitdivine]

For what it's worth, M1 runners are coming to GitHub actions this Winter: https://github.com/orgs/github/projects/4247/views/1?filterQuery=-status%3A%22Q4+2022+%E2%80%93+Oct-Dec%22+M1

[ggreif]

In the meantime there is https://twitter.com/domenkozar/status/1674792337040629770

[ulan]

@EnzoPlayer0ne is working on setting up an M1 builder and publishing M1 native binaries of replica, ic-starter, and sandbox. Once that done, would the SDK team be able take the binaries and release an M1 native dfx?

On some heavy workloads the performance difference between Apple and Intel binaries on M1 is significant. For example, I observed the difference of 4x on Macbook Air M1.