cross fail to build futures-util v0.3.25 due to version GLIBC_2.28' not found`

[NobodyXu]

Checklist

• I've looked through the issues and pull requests for similar reports

Describe your issue

After bumping tokio from 1.23.0 to 1.24.1 cargo-bins/cargo-binstall#658 , cross failed to cross-compile cargo-binstall due to:

error: failed to run custom build command for `futures-util v0.3.25`

Caused by:
  process didn't exit successfully: `/target/debug/build/futures-util-66db01e574f92740/build-script-build` (exit status: 1)
  --- stderr
  /target/debug/build/futures-util-66db01e574f92740/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /target/debug/build/futures-util-66db01e574f92740/build-script-build)
warning: build failed, waiting for other jobs to finish...
error: Recipe `check` failed on line 117 with exit code 101
Error: Process completed with exit code 101.

What target(s) are you cross-compiling for?

aarch64-unknown-linux-gnu, aarch64-unknown-linux-musl, armv7-unknown-linux-gnueabihf

Which operating system is the host (e.g computer cross is on) running?

• macOS
• Windows
• Linux / BSD
• other OS (specify in description)

What architecture is the host?

• x86_64 / AMD64
• arm32
• arm64 (including Mac M1)

What container engine is cross using?

• docker
• podman
• other container engine (specify in description)

cross version

cross 0.2.4

Example

No response

Additional information / notes

Cross compilation to armv7-unknown-linux-musleabihf succeeded.

[Emilgardis]

This is #724, you're sharing cache between workflows

See https://github.com/cargo-bins/cargo-binstall/actions/runs/3870471673/jobs/6597419861#step:3:54 and
https://github.com/cargo-bins/cargo-binstall/actions/runs/3870471673/jobs/6597419564#step:3:70, they are using the same cache key

[NobodyXu]

Aha, I guess the armv7-unknown-linux-gnueabihf release build failure is caused by the same reson cargo-bins/cargo-binstall#670

[Emilgardis]

Yep, that one is using the same cache as https://github.com/cargo-bins/cargo-binstall/actions/runs/3870358671/jobs/6597650761#step:3:76

the problem is basically that

• the containers cross uses has a lower glibc than available on githubs ci runners.
• when using build-scripts, the only time they are rebuilt is on changes to rustc itself, paths pointed to with cargo:rerun-if-changed or env vars with cargo:rerun-if-env-changed
• in consequence, this means that the faster build that gets cached has their build-scripts cached, and since in general the workflow that is not ran through docker is most likely the fastest, its build scripts will be the ones used in future runs.
• since the build script that was cached has a higher glibc linked in, they can't run inside the docker image with a lower glibc

[NobodyXu]

Thanks for the explanation, this is probably a cargo-binstall workflow issue due to recent changes to it.