[TRACKING] Packages unable to cross-build due to rust's autocfg

[cinerea0]

Some rust packages are currently failing to cross-build because they depend on indexmap. A default hash builder only exits for std builds; this is checked in indexmap's build.rs file, and that test is currently failing for us. We don't want to fix it with the environment variable because the autocfg tests should be working.

Packages that have been merged:

• alacritty (bb09652)

Packages with open PRs:

• sequoia-sq (New Packages: sequoia cli utilities #32480)

Fixed packages:

• bat (bat: update to 0.20.0. #34966)
• delta (48fa12c)
• git-cliff (git-cliff: update to 0.6.0. #35489)
• gitui (gitui: update to 0.20.1. #35490)
• mdcat (66eaeca)
• rust-analyzer (rust-analyzer: update to 2022.01.03. #34856)
• starship (starship: update to 1.2.1 #34850) (Fixed on its own)
• texlab (9f22215)
• tree-sitter (a93c532)

[abenson]

indexmap is the first thing most things fail on, but there are more all centered around autocfg.

[ericonr]

🙃

[cinerea0]

I'm going to start a separate comment to list packages that have the error but haven't been merged or don't have open PRs since they're not as high priority. The list:

• fselect

[ericonr]

I came across this while investigating, might have something to do with it LibreELEC/LibreELEC.tv#5446

rust-lang/cargo#9322 got merged right after the release we were using. Should be unstable and not affect anything, but who knows for sure.

cuviper/autocfg#15 might be the relevant one? but unsure

[jcgruenhage]

Considering this affects quite a few packages by now, and I haven't seen a big push to solve this yet, does it maybe make sense to mark these as nocross for now, with a reference to this tracking issue?

[paper42]

gitui is another one: #35490

[tranzystorekk]

From google/cargo-raze#114 (comment):

(Nitty gritty aside: It seem the way this works is the autocfg library tries to run rustc over a file containing the single "extern $some_crate", and identifies whether or not that compiles)

Maybe trying to build a file like:

extern crate std;

on the failing targets could point to the cause of this problem?

[tranzystorekk]

Did a bit of analysis on a test repo where I added some debug printouts to autocfg, and I seem to have found the problem.

When autocfg probes for the std crate, it runs a custom rustc command with arguments that try to mimic the settings of the crate that is being built. In our case, that should include a custom --sysroot=<XBPS_CROSS_BASE>/usr argument, pointing to the rust-std install for the cross target.

Unfortunately, we pass this as the RUSTFLAGS environment variable, and the build.rs script run, being a subprocess in a new shell context, doesn't see any RUSTFLAGS in its environment.

In the end the rustc probe is run with almost all the needed arguments, except for the --sysroot.

EDIT 1: There also seems to be a general issue with passing RUSTFLAGS to build scripts: rust-lang/cargo#4423
EDIT 2: The issue seems to be mitigated in autocfg 1.1.0, where it also tries to read CARGO_ENCODED_RUSTFLAGS, which as I checked is set by cargo in general when crossing in xbps-src

[tranzystorekk]

It's probably unreasonable to skip the affected packages' versions, but I'm not sure if we can somehow make patches that force just the autocfg bump, similar to running cargo update --package autocfg