Fix native-image mapping for aarch64, #474

[lanmaoxinqing]

No description provided.

[ppalaga]

There is no way to test this on GH actions yet.

[lanmaoxinqing]

There is no way to test this on GH actions yet.

I'll glad to update GH actions to support aarch64 builds.

But before that, i find jansi-native also do not support aarch64 due to same problem.

So this fix cannot actually work until we release a newer jansi version with aarch64 support.

[ppalaga]

There is no way to test this on GH actions yet.

That was just a side note, not a reason against this, sorry :)

I'll glad to update GH actions to support aarch64 builds.

I wonder how? AFAIK aarch64 is not supported yet.

[lanmaoxinqing]

That was just a side note, not a reason against this, sorry :)

Oh i just mean that it's my pleasure to update GH actions~ sorry for my poor english :->)

I wonder how? AFAIK aarch64 is not supported yet.

AFAIK the platform dependent part of mvnd is native image building and jansi dependency, it only needs a few work to compat with aarch64, and it's my pleasure to figure it out if i'm wrong :)

Then just like how we have done in jansi, my idea is to use docker image multiarch/crossbuild to build and test aarch64 releases in GH actions.

linux-arm64:
	docker run -it --rm -v $$PWD:/workdir -e CROSS_TRIPLE=aarch64-linux-gnu multiarch/crossbuild make clean-native native OS_NAME=Linux OS_ARCH=arm64

[ppalaga]

I wonder how? AFAIK aarch64 is not supported yet.

AFAIK the platform dependent part of mvnd is native image building and jansi dependency, it only needs a few work to compat with aarch64, and it's my pleasure to figure it out if i'm wrong :)

Then just like how we have done in jansi, my idea is to use docker image multiarch/crossbuild to build and test aarch64 releases in GH actions.

linux-arm64:
	docker run -it --rm -v $$PWD:/workdir -e CROSS_TRIPLE=aarch64-linux-gnu multiarch/crossbuild make clean-native native OS_NAME=Linux OS_ARCH=arm64

Thanks for the explanation (I am really unexperienced with arm builds and testing on Linux)
What you mention covers the building of the aarch64 binary - that's valuable.
However, it is still unclear to me whether/how the crossbuild image can help with testing the aarch64 binary on GH Actions?

[ppalaga]

Running our tests also on aarch64 would be nice, but it is not a blocker in case there is no way to do it on GH Actions or on some other free CI.

[lanmaoxinqing]

Running our tests also on aarch64 would be nice, but it is not a blocker in case there is no way to do it on GH Actions or on some other free CI.

You are right. The solution above can only test and build binary in docker but not directly in GH actions, which can not block invalid PRs.

Specify a arm64 machine to run GH actions will be the best solution, but it seems that only self-hosted machines is supported so far.

• adding-self-hosted-runners
• using-github-actions-to-test-your-go-code-on-arm64

[electrum]

You can use https://github.com/docker/setup-qemu-action to allow running arm64 Docker images on GH actions:

- uses: docker/setup-qemu-action@v1
  with:
    platforms: arm64

[lanmaoxinqing]

You can use https://github.com/docker/setup-qemu-action to allow running arm64 Docker images on GH actions:

That’s great! I will try it later when i finish my current works, thanks for your help~