Closed taiki-e closed 2 years ago
The underlying problem seems to be that
cross
uses by defaultmain
tag that may be incompatible with the current version. Using the tag that matches the version (0.2.4
in this case) seems to work around the problem.
Fixing the underlying problem (i.e., using an image known to be compatible with the current version by default) will avoid similar breakage in the future, but will not fix the problem occurring in the current release. In any case, it seems that aarch64-linux-musl-gcc.sh
needs to handle the case where the CROSS_RUSTC_MINOR_VERSION
environment variable is not present. Something like the following:
if [[ -z "${CROSS_RUSTC_MINOR_VERSION:-}" ]]; then
CROSS_RUSTC_MINOR_VERSION=$(rustc -Vv | grep '^release:' | cut -d ':' -f2 | cut -d '.' -f2)
fi
In summary, there's 2 issues here:
main
is the correct tag, while cargo install cross
uses 0.2.4. This means we've had breaking changes released to users thinking they had a non-breaking release.This was changed in #1028. cross
should only use the main tag if installed from git
, otherwise it should use the 0.2.4 tag (or whatever version was installed). But maybe we should provide a fallback since this will likely affect a few people. We can always use our Rust version detection if the variable isn't present, and then remove that with the 0.3.0 release.
There is, however, another issue if the released cross version isn't using a released tag, since we've made numerous backwards incompatible changes since then. This seems to be an issue specifically with using bininstall or installing cross from a pre-built binary. Normally, using cargo install cross
and cross --version
shouldn't have the hash or the release date, and therefore should use the $image:0.2.4
tag. However, those binaries as I've checked do have the commit hash and release date, and they're from the same commit as the actual release.
@Emilgardis know how to fix the pre-built binaries? We should provide a fallback for the time being and also likely release 0.2.5
for the pre-compiled binaries.
I can provide a quick fallback (similar to what we did in #1028) but we also have a much larger issue here as well: that we've also been making backwards-incompatible changes to our images which are used by an incompatible version of cross installed from a pre-compiled binary.
This also affects a few MIPS targets and an ARMv5TE target.
The same error also happened in cargo-binstall
https://github.com/cargo-bins/cargo-binstall/actions/runs/3170447340/jobs/5164006948
The same error also happened in
cargo-binstall
https://github.com/cargo-bins/cargo-binstall/actions/runs/3170447340/jobs/5164006948
Yep this is an issue when cross is installed but not built from source from crates.io, IE, when not using cargo install cross
. Download the binary from a tarball or using bininstall
(or using any that installs a binary via bininstall
, such as install-action
[correct me if I'm wrong on that one]) will produce the above error. cross
only uses the version release tag and not main
when using cargo install cross
. To fix this, we need 2 steps:
bininstall
(I have no idea how complex this will be).Download the binary from a tarball or using bininstall (or using any that installs a binary via bininstall, such as install-action [correct me if I'm wrong on that one])
I think you mean binstall
or cargo-binstall
right?
There's bininstall
but I think that is a typo.
Fix our released tarballs that are used by bininstall (I have no idea how complex this will be).
For cargo-binstall
, IMO release a new minor version v0.2.5
will surely fix the bug.
Replacing the existing v0.2.4
artifacts would work but doesn't sound like a good approach to this.
This should be solvable by removing .git before compiling. We should maybe revert the env var change, republish 0.2.4 (and maybe a 0.2.5 ?) to then introduce it again
the 0.2.4 changes can be done manually
any that installs a binary via
bininstall
, such asinstall-action
[correct me if I'm wrong on that one]
For cross
, install-action
downloads a tarball from the GitHub release of this repo directly, not via a third-party tool.
I've created https://github.com/cross-rs/cross/tree/v0.2.4-fix from which we can grab the artifacts and replace
canceled the run for now to let ci build #1047
The backwards incompability has been fixed now, remaining task now is to fix the 0.2.4
binaries on the release
I have updated the binaries on the release.
https://github.com/cross-rs/cross/releases/tag/v0.2.4
This should now be resolved
I've confirmed that it has been fixed in my use cases. Thanks for the swift fix!
Checklist
Describe your issue
https://github.com/cross-rs/cross/commit/9311417f7d251103c21f547aa341e643f08a5fd8 added
CROSS_RUSTC_MINOR_VERSION
environment variables without fallback, so the current docker image of themain
tag is incompatible with the released version of cross (v0.2.4).log: https://github.com/taiki-e/cargo-llvm-cov/actions/runs/3170903254/jobs/5163844829
The underlying problem seems to be that
cross
uses by defaultmain
tag that may be incompatible with the current version. Using the tag that matches the version (0.2.4
in this case) seems to work around the problem.What target(s) are you cross-compiling for?
aarch64-unknown-linux-musl
Which operating system is the host (e.g computer cross is on) running?
What architecture is the host?
What container engine is cross using?
cross version
cross 0.2.4 (4645d93 2022-07-10)
Example
Probably this can also be reproduced with a crate created with
cargo new --bin
instead of cargo-llvm-cov.Additional information / notes
No response