readme table needs to be updated.

You can generate the table with

cargo xtask target-info --tag local (all the images need to be built though beforehand)

bors try --target linux

try

Build failed:

• conclusion

Marked this for the 0.4.0 milestone since it updates glibc from 2.21 to 2.35, which isn't supported on any Debian distribution as of yet (even on the unstable release, sid).

Looks like the error in the images containing a Linux image for full system emulation have an unrelated error:dropbear-2022.82 has a 520 error right now. We might need to switch to another mirror if this stays for a while. Amirror exists if needed.

Now that the mirror issues have been fixed...
bors try

try

Build failed:

• conclusion

seemsbzip2 is no longer in default installation

seemsbzip2 is no longer in default installation

That should probably be done explicitly too, since if it's already installed, we can just purge it later.

Looks likencurses-base is no longer a valid package or has no installation candidate: all thelinux-image.sh scripts are failing with:

apt-get -d --no-install-recommends download libcrypt1:mips64el busybox:mips64el dropbear-bin:mips64el libtommath1:mips64el libtomcrypt1:mips64el libgmp10:mips64el libc6:mips64el linux-image-5.10.0-16-5kc-malta:mips64el ncurses-base zlib1g:mips64el#22 20.92 E: Can't find a source to download version '6.3-2' of 'ncurses-base:amd64'

Looks likencurses-base is no longer a valid package or has no installation candidate: all thelinux-image.sh scripts are failing with:

apt-get -d --no-install-recommends download libcrypt1:mips64el busybox:mips64el dropbear-bin:mips64el libtommath1:mips64el libtomcrypt1:mips64el libgmp10:mips64el libc6:mips64el linux-image-5.10.0-16-5kc-malta:mips64el ncurses-base zlib1g:mips64el#22 20.92 E: Can't find a source to download version '6.3-2' of 'ncurses-base:amd64'

Oh, the issue is Ubuntu 22.04 added the packagencurses-base, which has version6.3-2, which is higher than thencurses-base in bullseye (6.2+20201114-2). We should also be using bookworm or sid for this upgrade as well, since Ubuntu 22.04 is based off of those versions. We also might need to choose an exact installation candidate, similar to how we do so for conflicting packages on amd64 inlinux-image.sh.

Is there anything I can help here?

In the meantimebindgen removedsupport for ancient clang versions. The clang version in 18.04 is considered ancient.
As a resultbindgen (>=0.60.0) doesn't work in any of those images out of the box. Probably a solution would be to upgradeclang in a customDockerfile which is required anyways to install the bindgen requirements.

Is there anything I can help here?

In the meantimebindgen removedsupport for ancient clang versions. The clang version in 18.04 is considered ancient. As a resultbindgen (>=0.60.0) doesn't work in any of those images out of the box. Probably a solution would be to upgradeclang in a customDockerfile which is required anyways to install the bindgen requirements.

We use 20.04 on the latest mains and are working on a 0.3.0 release currently. I believe those should still work with bindgen. We'd like ideally to have a release on 20.04 before migrating to 22.04, personally, and I'd like a few bug fixes in the meantime. I'll test this later today with a more recent build.

Is there anything I can help here?
In the meantimebindgen removedsupport for ancient clang versions. The clang version in 18.04 is considered ancient. As a resultbindgen (>=0.60.0) doesn't work in any of those images out of the box. Probably a solution would be to upgradeclang in a customDockerfile which is required anyways to install the bindgen requirements.

We use 20.04 on the latest mains and are working on a 0.3.0 release currently. I believe those should still work with bindgen. We'd like ideally to have a release on 20.04 before migrating to 22.04, personally, and I'd like a few bug fixes in the meantime. I'll test this later today with a more recent build.

Thanks. I didn't know that there's 20.04 in between. Haven't tried but it's very likely this works.

Any plans to include thebindgen dependencies by default? I have multiple projects with aCross.toml and Dockerfiles just for adding thebiindgen dependencies.

Any plans to include thebindgen dependencies by default? I have multiple projects with aCross.toml and Dockerfiles just for adding thebiindgen dependencies.

Not currently, the clang deps take up a lot of space.

You can skip the additionalDockerfiles and only use aCross.toml (or even justCargo.toml likethis)

# Cross.toml[target.TARGET]pre-build = ["apt-get update && apt-get install --assume-yes --no-install-recommends libclang-3.9-dev clang-3.9"]

What's the ETA on this change? currently unable to compile anything using libssl as Ubuntu 20.04 only provides libssl1 while every distro now uses libssl3, and Ubuntu 22.04 doesn't have an official package for libssl1.

What's the ETA on this change?

there is no ETA on 0.4.0, we still have to do 0.3.0 which needs on other changes. development has slowed down a bit due to availability, but any help is greatly appreciated

Is there a TODO list on this?

I wonder if it's worth going straight to Ubuntu 24.04 LTS now instead of 22.04

I wonder if it's worth going straight to Ubuntu 24.04 LTS now instead of 22.04

On a related note, I think it is totally worth having an Arch Linux image that is automatically periodically updated. It may be burdensome for the team to be on their toes updating for SSL or other things.

I've not been keeping up with this project, but didn't it use old versions of Ubuntu for minimizing the glibc version to link against for broader portability?

These days you can usecargo zigbuild to cross compile to targets. It handles the glibc minimal version for you so that you can run on a modern distro release, and you don't have to worry about toolchains for different archs, just add the targets via rustup IIRC.

@polarathene yes that was one of the reasons for a older release, but we've moved away from that philosophy.
We also provide zigbuild withtarget.<target>.zig the only problem with that is cross-compiling with dependencies.

the only todo for this is to release 0.3.0 first@pvshvp-oss

We don't provide ssl in our images (except freebsd) for exactly the reason of having to update, instead you have to manually pull the dependency via something likeprebuild

we also have a centos based image, making a archlinux based image shouldn't be too hard:https://github.com/cross-rs/cross/blob/7d75864e7812005156805587838f41eb3b30a270/docker/Dockerfile.native.centos

I assume that by now this should be closed in favor of cross using Ubuntu 24.04?

I'll keep it open, but yes, it would probably make sense to jump directly to 24. I've previously said though that we should release 22.04 first but I think that would not be wise anymore.