ARM builds for Linux

[alcuadrado]

With Apple switching to ARMv8 releasing ARM builds of solc is increasingly important, especially linux ARM builds.

The reason for this is that if you use Docker with an ARM mac, you'll end up running your containers in an ARM-based Linux, so you can't run any native solc build.

In Mac the situation is different, you can still run x86_64 binaries using Rosetta2, and this process is 100% transparent.

Hardhat, and I guess all the other Node.js-based tools, automatically fallbacks to socjs, so it still works in ARM-based Docker containers. Other tools, like Brownie, probably break in that situation.

[axic]

We have set up ARM builds on another project, but it is rather computationally expensive as it is running in an emulator. I wonder how big of a slowdown that would be for running soltest within that emulator, because without running tests we can't be satisfied it actually works, which reduces its usefulness.

And as you said, macOS still works out of the box. We are waiting for CircleCI to release support, which they may do this year :sweat:

However I really wonder why would projects start doing an ARM Linux build, which is not really used outside of RaspberryPI PC builds? Why not just wait for proper macOS build environments, as that is the target people actually have? Do you know of an example project which already does this?

[alcuadrado]

The only reason I can think of is because of docker running on an M1 mac. It's really annoying, because switching to arm in a mac is pretty straightforward, except when using docker.

There are probably other reasons though, as some projects, like Node.js were already distributing ARM linux builds.

[axic]

Are you saying Docker on an M1 mac virtualises ARM and is not running on top of Rosetta? Yeah that may be an annoying situation and a strong enough reason.

Though I personally only used docker once or twice on a mac because it was so dead slow compared to linux.

[alcuadrado]

Are you saying Docker on an M1 mac virtualises ARM and is not running on top of Rosetta?

Yes, exactly. Docker desktop runs an arm linux vm and the containers inside it.

Though I personally only used docker once or twice on a mac because it was so dead slow compared to linux.

Yeah, it's annoying. I think the slow down is because of the vm.

[cameel]

This should be now possible. On our last call with people from CircleCI they had this in their presentation:

Key Releases Past 6 Months

• ARM Cloud Support
  • Medium and large ARM machines are now a part of our cloud platform
  • Documents here: https://circleci.com/docs/2.0/arm-resources/

Arm Resources on CircleCI

February 01, 2021

We have initiated a preview of hosted Arm resources on CircleCI. Arm is an architecture that is quickly gaining traction for server workloads. Organizations choose Arm because of its faster performance, which results in faster workloads and significant cost savings compared to x86-based architectures. An essential piece of migrating workloads to Arm is having Arm support in your CI system. If you are on a usage-based plan, including the Free plan, you may request access to the Arm preview. We are making two arm64 resources available: arm.medium and arm.large.

To request access, customers must fill out an access form that is linked in the preview docs below.

[dezzeus]

Any update ? @cameel

[cameel]

Sorry, nothing yet. We'll get to this eventually but in the short term there are a few things from our roadmap that have priority, like getting the IR compilation pipline ready for general use.

[gakonst]

FYI @nikitastupin went ahead and made a GHA release flow here https://github.com/nikitastupin/solc/. Would love exploring a way to get this upstreamed.

[cameel]

That looks nice. This is only for the latest version though, isn't it? I don't see any workarounds that would probably be required to build earlier versions. I mean, if none are needed then great, but I needed a ton when I did builds for macOS earlier (see how gnarly random-macosx-build.yml is :))

But anyway, if you're interested in upstreaming this, I don't think we'd accept binaries but if @nikitastupin is willing to refactor this script to work in a similar vein to random-macosx-build.yml, we'd run it in our CI and build them ourselves.

One important thing is that the script must run our test suite on the built binary to verify it's built correctly. At least to the extent that these older versions allowed - the oldest ones didn't and later ones could run only part of the test suite without setting up a node. The action you linked to does not do this and this part is actually what added a lot of complexity in the macOS case. I think it's crucial though.

If you do this, you can submit the script in a PR to solc-bin and I'll help reviewing it. Here's my PR for macOS: https://github.com/ethereum/solc-bin/pull/53 for reference. See in particular https://github.com/ethereum/solc-bin/pull/53#issuecomment-700149493, which explains the specific workarounds needed - most of which hopefully will not be needed on Linux.

Once the binaries are built, I'll submit them in a separate PR, which will trigger the bytecode comparison check (t-bytecode-compare.yml). This will ensure that the bytecode produced by the binaries is identical with other platforms, at least to the extent covered by our tests.

---

This is only about rebuilding existing versions though. Another part of this task is to add the new platform to our release process. This is fairly straightforward and the blocker here was simply lack of support on CircleCI's part. If you want to submit a PR for that part, it would basically be this: 1) Add a CircleCI job similar to b_ubu_static but running on ARM.

• I think we'll also need equivalents of t_ubu_soltest and t_ubu_cli jobs for this platform. 2) Update ReleaseChecklist.md.

[axic]

It is possible now to use CircleCI's ARM machines, but the image they have is a rather old Ubuntu. We use it in Fizzy:

  arm64-native:
    machine:
      image: ubuntu-2004:current
      resource_class: arm.large
    steps:

[axic]

Even windows+arm is now supported on github actions too: https://github.blog/changelog/2022-09-28-github-actions-self-hosted-runners-now-support-windows-arm-hardware/