M1 Mac - target x86_64 without AVX is not yet supported

[romanzac]

Hi,

It has been a while since M1 Mac come to live, so I wonder if Kurtosis NEAR module also supports them? I am following guide here: https://docs.near.org/develop/testing/kurtosis-localnet

After I deploy test smart contract, I am getting error during function call.

local_near call $ACCOUNT_ID new_default_meta '{"owner_id": "'$ACCOUNT_ID'"}' --accountId $ACCOUNT_ID

Doing account.functionCall() Receipt: ASpqNKvHythgSiwnPqU1FkMr2nugsxn7f1y2q85fu7oU Failure [test.near]: Error: Wasmer compilation error: The target x86_64 without AVX is not yet supported (see https://docs.wasmer.io/ecosystem/wasmer/wasmer-features) ServerTransactionError: Wasmer compilation error: The target x86_64 without AVX is not yet supported (see https://docs.wasmer.io/ecosystem/wasmer/wasmer-features) at Object.parseResultError (/usr/local/lib/node_modules/near-cli/node_modules/near-api-js/lib/utils/rpc_errors.js:31:29) at Account.signAndSendTransactionV2 (/usr/local/lib/node_modules/near-cli/node_modules/near-api-js/lib/account.js:160:36) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async scheduleFunctionCall (/usr/local/lib/node_modules/near-cli/commands/call.js:57:38) at async Object.handler (/usr/local/lib/node_modules/near-cli/utils/exit-on-error.js:52:9) { type: 'WasmerCompileError', context: undefined, index: 0, msg: 'The target x86_64 without AVX is not yet supported (see https://docs.wasmer.io/ecosystem/wasmer/wasmer-features)', kind: { msg: 'The target x86_64 without AVX is not yet supported (see https://docs.wasmer.io/ecosystem/wasmer/wasmer-features)' },

Thanks for any advice. Potentially I can help with porting. R.

[romanzac]

Where should I start ? What would be the best option for now ? 1) Porting to ARMV8 2) Omitting AVX instruction requirement from x86 compilation for non production environment ...

Which package/docker container needs a change?

[mieubrisse]

Hey @romanzac , thanks for reporting this! Let me check with the NEAR team to see exactly what this guy means, as it's not completely clear to me why this is breaking

[romanzac]

ARM will always beat x86_64 on performance / watt. It is because number of transistors required for CISC architecture is higher. AWS already offers ARM instances. I think making NEAR the greenest blockchain on the planet won't be possible without porting to ARM. It is not only about Apple and local dev env.

[mieubrisse]

What I asked Vlad Frolov from the NEAR team:

Hey Vlad, superquick question about NEAR contracts and WASM - does https://github.com/kurtosis-tech/near-package/issues/21 mean that the user compiled the contract on an M1 machine and is trying to run it on x86? or is it the reverse - that the NEAR node is compiling on x86 and the M1 underlying machine doesn't understand it (likely because of lack of Rosetta)?

His response:

I believe the error comes from the Wasm VM in nearcore attempting to execute the contract. As far as I remember, only debug nearcore builds run on M1 as release build requires certain version of Wasm VM which (last time I checked a half a year ago) did not support ARM (M1)
I’m not the right person to ask further clarifications, you will need someone from nearcore runtime team

Going to post an issue on the nearcore for @romanzac

[mieubrisse]

Actually I think this is probably the most relevant thing: https://github.com/near/near-indexer-for-explorer/issues/278 I think the best thing here would be for us to publish M1-built images and see if this resolves it

[mieubrisse]

Created #30 to track

[romanzac]

Let me try to build near-indexer-for-explorer image on my M1

[romanzac]

I found yesterday build Docker image instructions for "near-indexer-for-explorer" are not valid anymore. I tried to build docker images for particular services and compilation for target "aarch64-unknown-linux-gnu" went ok.

This StarLark file probably needs update too: https://github.com/kurtosis-tech/near-package/blob/master/src/services/indexer.star

Is anyone working on this update ? If not, it would take me some time, so I understand in greater detail what is indexer actually doing and how to run it in enclave.

[trileeeee]

Hey @romanzac, I'm working on building the image in ARM and will update here if this build fix the problem.

[romanzac]

Looking forward...

[trileeeee]

Hey @romanzac, good news here, the ARM image did resolve the problem. I will try to start the process of publishing this image into the Kurtosis Image Repository and will ping you again when it is live

[romanzac]

Hi @trileeeee , thanks for your quick response. Great news indeed.

[Codie-Petersen]

@romanzac

It's @trileeeee weekend right now, but he got the image to me last night to look over and verify.

Github doesn't allow TAR uploads so I have put the image in Google Drive for you here. For anyone else having problems with this that needs an immediate solution, I will put the steps in here. It is only temporary and you should use the launch script as normal after Kurtosis uploads their files to their repo and closes this issue in a couple of days.

1. Make sure Kurtosis Engine and Docker are running.
2. Clean Kurtosis with kurtosis clean -a.
3. Run ./launch-local-near-cluster.sh script as you would normally to make sure you have all of the latest images.
4. Clean Kurtosis again.
5. Next find the kurtosistech/near-indexer-for-explorer image in Docker and delete it.
6. In terminal, change directory to the location where your downloaded near-indexer-for-explorer-multi-arch-image.tar is located.
7. Run docker load --input near-indexer-for-explorer-multi-arch-image.tar. This will load the image into docker with the same name as the original Kurtosis indexer.
8. The next part is crucial for the fix. In order for the image to be used, the launch-local-near-cluster.sh must not overwrite the newly loaded image with the current Kurtosis repo image. So you will need to turn off your internet as the script Is trying to pull the images. You can turn it back on, but not until the launch script is done running.
   1. Change directory to your launch script.
   2. Run ./launch-local-near-cluster.sh
   3. You should see 3 INFO lines, then 3 lines starting with > print, finally you should see add_service service_id="contract-helper-db”.
   4. The moment you see that line, turn off your internet. It hangs for a couple of seconds, so you should have time.
   5. The image below is about what you should see. The second to last line is when you should turn off your internet.
   6. 
   7. The script will continue to use the images already on your computer rather than redownloading them.
   8. Once it is finished, you can turn your internet back on.

At this point everything should work. I have tested a view and call with this on a simple hello world contract. Let us know if there are still problems.

[romanzac]

@Codie-Petersen I am sorry I will have a look next week.

[Codie-Petersen]

No worries @romanzac. We'll keep you updated as well if it gets rolled out officially too.