-
Notifications
You must be signed in to change notification settings - Fork 386
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
Tracking Issue for Aarch64 Images #975
Comments
If we install packages from Debian for some of these toolchains, we can support a lot more architectures. Potential solutions include:
This only seems to affect MIPS however. |
Just observation I encountered issue with latest libc crate (0.2.126) requiring newer glib version
It would be good to consider bumping ubuntu images as they have relatively old glib for cross compilation |
That's unrelated (and an upstream bug): see #724. Try running |
This comment was marked as off-topic.
This comment was marked as off-topic.
I downloaded an aarch64 image to my host (my M1 mac). Would someone tell me how to use it? I've got a knowledge gap between having the native (M1, aarch64) image and this command: I think for me the Thank you |
Do you need CROSS_TARGET_ARMV7_UNKNOWN_LINUX_MUSLEABIHF_IMAGE=ahuszagh/aarch64-cross:armv7-unknown-linux-musleabihf \
cross build --release --target=armv7-unknown-linux-musleabihf Does that help? All the image names and tags can be found here. |
@Alexhuszagh Thanks, that does look more like what I need however with that I get,
|
Is your local machine the M1? Or are you connecting remotely to it? If so, then you do need |
Local is M1. No physically remote build computer yet. Hoping to avoid that |
Ah I think I know what the issue is. Sorry for the repeated mentions. You need to do the instructions under target.TARGET.image, or provide them as environment variables. So the full invocation is: CROSS_TARGET_ARMV7_UNKNOWN_LINUX_MUSLEABIHF_IMAGE_TOOLCHAIN="aarch64-unknown-linux-gnu" \
CROSS_TARGET_ARMV7_UNKNOWN_LINUX_MUSLEABIHF_IMAGE=ahuszagh/aarch64-cross:armv7-unknown-linux-musleabihf \
cross build --release --target=armv7-unknown-linux-musleabihf If we deploy native ARM64 images, this should be streamlined a lot later on (we need custom runners which aren't free), but right now it's a bit janky. Does that fix the issue? |
Are you kidding? Thanks for being so generous with your time and expertise! Success! 🎉 Here are some test results (docker images already automatically downloaded so time to download those not included): Build time with default build image
Build time with native aarch64 (M1) build image:
Summary: About 6.5 minutes (73%) faster! |
Cross's android images are causing CI to fail. Maybe related: cross-rs/cross#975
Cross's android images are causing CI to fail. Maybe related: cross-rs/cross#975
@Alexhuszagh has pushed initial images here as mentioned in this issue. We have not started implementing this in-org yet, and thus they are not on ghcr.io/cross-rs. You can also build these images yourself |
Hey @Alexhuszagh Kudos on the awesome tracking list, I have this saved as a bookmark, was SUPER useful for me, in my current ARMaggedon flex on our open source project. Linked PR above ☝🏾 to attempt to cover off the case for |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
1271: feat: add aarch64-unknown-freebsd image r=Emilgardis a=YOU54F 👋🏾 Thanks for Cross, we've been using it at the pact-foundation to build cross platform targets, and I've gone through the target list and attempted to build for everything I can. See [PR here](pact-foundation/pact-reference#276) I've managed to build for freebsd in a parallels vm on a mac m1 pro, but makes sense to try and apply that to a Docker image. Relates to #975 Still requires testing but thought I would drop it here for others to have a look at / test / try out Co-authored-by: Yousaf Nabi <you@saf.dev>
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Configuring a https://github.com/mcandre/tug Recommend to house this configuration in direnv / psenv, in order to reduce conflicts between different software projects you may be working on. |
Hi @Alexhuszagh ! |
I'm trying to install My cross file looks like this:
But when I run:
I get the following error:
I've tried a bunch of stuff in the pkg-mngt wrangling but no success. At one point I got it to be located but it wouldn't install because of issues with libc toolchain not being available. I was able to build successfully by directly installing the .deb packages, but my preference is to use apt. I've read the docs linked from the README a few times but I feel like I'm missing something here about the problem I'm facing. edit: Is it possible to get command output from the docker setup? I can see the command thats running with |
Yes, simply add |
This is a tracking issue for building aarch64 images, meaning they run natively on linux/arm64 instead of linux/amd64, and what's confirmed to work, what needs to be fixed, and what's currently untested, so we can ensure the maintainers don't duplicate work, new contributors know where to start, and looking at what to patch for future builds. We can also likely add builds for PPC64LE, since almost all of the maintained packages that have install candidates for ARM64 also support PPC64LE. Currently, most of the linux GNU packages are/will be failing.
Note that the PPC64LE images are currently untested, but assumed to work.
Currently Succeeding
Builds of these images for aarch64 can be found here for debugging and testing purposes (these are not official images, not are they guaranteed to be stable).
aarch64-unknown-linux-gnu
(x86_64, i686, arm64, ppc64le, depends on Add concept of a native Dockerfile. #982)s390x-unknown-linux-gnu
(x86_64, i686, arm64, pp64le)arm-unknown-linux-gnueabi
(x86_64, i686, arm64, pp64le)armv5te-unknown-linux-gnueabi
(x86_64, i686, arm64, pp64le)armv7-unknown-linux-gnueabi
(x86_64, i686, arm64, pp64le)armv7-unknown-linux-gnueabihf
(x86_64, i686, arm64, pp64le)i586-unknown-linux-gnu
(x86_64, arm64, pp64le)i686-unknown-linux-gnu
(x86_64, i686, arm64, pp64le)powerpc64le-unknown-linux-gnu
(x86_64, i686, arm64)riscv64gc-unknown-linux-gnu
(x86_64, i686, arm64, ppc64le)x86_64-unknown-linux-gnu
(x86_64, i686, arm64, ppc64le, depends on Add concept of a native Dockerfile. #982)aarch64-unknown-linux-musl
(likely all architectures)arm-unknown-linux-musleabi
(likely all architectures)arm-unknown-linux-musleabihf
(likely all architectures)armv5te-unknown-linux-musleabi
(likely all architectures)armv7-unknown-linux-musleabi
(likely all architectures)armv7-unknown-linux-musleabihf
(likely all architectures)i586-unknown-linux-musl
(likely all architectures)i686-unknown-freebsd
(likely all architectures)mips-unknown-linux-musl
(likely all architectures)mips64-unknown-linux-muslabi64
(likely all architectures)mips64el-unknown-linux-muslabi64
(likely all architectures)mipsel-unknown-linux-musl
(likely all architectures)sparcv9-sun-solaris
(likely all architectures)thumbv6m-none-eabi
(x86_64, armhf, arm64, pp64le, s390x)thumbv7em-none-eabi
(x86_64, armhf, arm64, pp64le, s390x)thumbv7em-none-eabihf
(x86_64, armhf, arm64, pp64le, s390x)thumbv7m-none-eabi
(x86_64, armhf, arm64, pp64le, s390x)thumbv7neon-unknown-linux-gnueabihf
(x86_64, armhf, arm64, pp64le, s390x)x86_64-unknown-freebsd
(likely all architectures)Currently Failing
arm-unknown-linux-gnueabihf
(Unknown error in crosstool-ng build process)sparc64-unknown-linux-gnu
(Unable to locate packageg++-sparc64-linux-gnu
, not available for ARM64, will need a full compile from source)mips-unknown-linux-gnu
(Package for ARM64 and PPC64LE only in 22.04+, not in 20.04)mips64-unknown-linux-gnuabi64
(Unable to locate packageg++-mips64-linux-gnuabi64
, not available for ARM64, will need a full compile from source)mips64el-unknown-linux-gnuabi64
(Unable to locate packageg++-mips64el-linux-gnuabi64
, not available for ARM64, will need a full compile from source)mipsel-unknown-linux-gnu
(Unable to locate packageg++-mipsel-linux-gnu
, not available for ARM64, will need a full compile from source)powerpc-unknown-linux-gnu
(Unable to locate packageg++-powerpc-linux-gnu
, not available for ARM64, only x86_64 and PPC64LE, will need a full compile from source)powerpc64-unknown-linux-gnu
(Unable to locate packageg++-powerpc64-linux-gnu
, not available for ARM64, will need a full compile from source)i686-pc-windows-gnu
(unlikely to work without building WINE from source)x86_64-pc-windows-gnu
(unlikely to work without building WINE from source)wasm32-unknown-emscripten
(nolinux/arm64
image for emsdk)x86_64-sun-solaris
(fails while building GCC).Failing, Cannot Fix
aarch64-linux-android
arm-linux-androideabi
armv7-linux-androideabi
i686-linux-android
thumbv7neon-linux-androideabi
x86_64-linux-android
The Android images have the following requirements, which means it will be impossible to build a cross-compiler for them without significant effort from a non-x86 host:
gcc-multilib
andg++-multilib
, which are not available on aarch64 and any host other than i686, x86_64, and s390x.clang
,gcc
andgo
that assume an x86 host.The only solution therefore would be to rebuild the entire NDK from source, get Android system, replace the prebuilts with native toolchains for a non-x86 host, update code so it uses the correct non-x86 prebuilts, etc. If this sounds like an issue, it is.
Currently Untested
x86_64-unknown-dragonfly
x86_64-unknown-illumos
x86_64-unknown-linux-gnu:centos
x86_64-unknown-linux-musl
x86_64-unknown-netbsd
Contributing
If you'd like to contribute your own tests, successes, etc., feel free to do so with the following examples. The runners, std, C++, and dynamic library support can be found in the Github actions
ci.yml
.The text was updated successfully, but these errors were encountered: