Use more cross-toolchains images by default

[mcandre]

Checklist

• I've looked through the issues and pull requests for similar request
• This feature could be solved with a custom docker image (optional)

Describe your request

When I run cross build for the first time, I expect it to be able to build macOS and other reasonable tier 1 support targets by default, using the cross system. Instead, I get a weird notice about missing Docker images.

$ cross build
[cross] warning: `cross` does not provide a Docker image for target aarch64-apple-darwin, specify a custom image in `Cross.toml`.
[cross] note: Falling back to `cargo` on the host.
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s

That is, it only managed to build the target due to happenstance of coding on a macOS host.

Well, it turns out that the cross GitHub org does have a related project, the cross-toolchains images, which does include images for cross-compiling to aarch64-apple-darwin.

Why does cross-rs/cross not know about cross-rs/cross-toolchains?

I would rather love to see cross consume these images by default.

As a workaround, the user technically has the option of manually configuring cross to consume the cross-toolchains images. But that involves extra steps, taking attention away from my main dev work. Again, I would expect cross to automatically incorporate these images out of the box.

Describe why this would be a good inclusion for cross

Better integration between the two cross-rs projects.

Better default cross behavior.

Less effort required by the cross user in order to build common, tier 1, cross-platform builds including macOS, Windows, and Linux.

[Emilgardis]

The images on cross-toolchains are not built by us and need to be built by the user, this is for various reasons.

The reason for not having darwin or msvc images pre-built is due to a unclear legal situation. I'm not sure how we could make this situation better

[mcandre]

Yes, Apple and Oracle have some rather antitrust practices that actually hurt adoption of their products. Until we get a case settled to get them to stop doing that, I suppose I can respect a rather defensive posture there by cross-rs direct contributors.

As for the rest of the images, would be nice to see them integrated more into the default cross experience. Or move the project to a different GitHub org to more clearly indicate a break in integration.

[Emilgardis]

I'm not sure I see the problem with them living in the organisation, imo moving them would only make it worse.

The reason we have https://github.com/cross-rs/cross-toolchains is because we'd like to support them, but they either break frequently, we can't distribute them or we don't distribute them because they are used for specific uses.

For example, s390x-unknown-linux-gnu-cross is available as a image on ghcr, but it's also on cross-toolchains where you can use crosstool-ng target for more specific needs.

[jsturtevant]

The reason for not having darwin or msvc images pre-built is due to a unclear legal situation

for mscv, I think there are provided images to build upon. https://devblogs.microsoft.com/cppblog/using-msvc-in-a-docker-container-for-your-c-projects. These are large images so it might be other challenges from a CI perspective.

[Emilgardis]

That's pretty much what we do @jsturtevant , the blog post mentions that you can't distribute them

Please don’t share these images on a public Docker hub.

[mcandre]

Irresponsible of Microsoft to not host their own official images for building Windows applications. That invites attackers to distribute their own images with malware provisioned by default.

Would love to see Rust include a complete toolchain of its own, especially a linker, to work around these hiccups.

[Emilgardis]

I think we can close this issue, if there are any setups on cross-toolchains or otherwhere that are able to be promoted into https://github.com/cross-rs/cross we can do that if there is a need and the build is stable enough and allowed to be distributed.

We have some issues for some targets

Android (with specific NDK/api): #1155
OpenBSD: #97

previous issues:

darwin: #508
msvc: #487