[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

[jcgruenhage]

If it's just updating autocfg to 1.1.0 in the deps, cargo update --package autocfg --precise 1.1.0 should do it, no need to actually write patches for that.

https://github.com/void-linux/void-packages/pull/35490/files#diff-6e15b2c2a57581f8262281a6d3343049c12e4de3c59ec1455fc8bb8027846d15R16-R18 is running that line in post_patch, which locally made cross compiling to aarch64 work for gitui locally. Let's see how that does for the other packages and other architectures in CI.

[jcgruenhage]

So yeah, seems like gitui and cargo-deny now pass their CI!

[tranzystorekk]

zellij also seems to build locally for aarch64 😄

[tranzystorekk]

Another problem with this issue in #35768. Probably cannot update autocfg to 1.1.0 there easily since the num-bigint-dig dependency selects autocfg ^0.1.5

[tranzystorekk]

As per cuviper/autocfg#40, autocfg 0.1 versions need to be updated to 0.1.8

[cinerea0]

Adding the following lines will likely fix any unfixed packages (credit to @tranzystorek-io) :

post_patch() {
	# fixes an indexmap error when cross compiling
	cargo update --package autocfg --precise 1.1.0
}

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[classabbyamp]

@cinerea0 can this be closed? It looks like there's a solution that can be applied if future issues appear, and every package listed has been fixed

[jcgruenhage]

Probably can be closed. One thing that might still be worth mentioning is that xlint requires specific versions by now, so the solution suggested here has to be adapted slightly:

cargo update --package autocfg:1.0.1 --precise 1.1.0
cargo update --package autocfg:0.1.7 --precise 0.1.8

The advantage here is that the specific version to update from and to ensures that cargo loudly complains if we update the package and the fix isn't required anymore, to not drag those fixes along for any longer than necessary

[cinerea0]

Yeah, this should be fine to close now that there's a general solution.