Repository navigation
[TRACKING] Packages unable to cross-build due to rust's autocfg #34889
Description
Activity
indexmapis the first thing most things fail on, but there are more all centered aroundautocfg.🙃
Reacted by Andrew Benson- changed the title
[-][TRACKING] Packages unable to cross-build due to rust's indexmap[/-][+][TRACKING] Packages unable to cross-build due to rust's autocfg[/+]on Jan 6, 2022 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
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
Reacted by TomConsidering 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?
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?
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
rustccommand 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>/usrargument, 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
rustcprobe 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 inautocfg1.1.0, where it also tries to readCARGO_ENCODED_RUSTFLAGS, which as I checked is set by cargo in general when crossing in xbps-srcReacted by Tom, JC Grünhage and Emi Vasilková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 autocfgIf it's just updating autocfg to 1.1.0 in the deps,
cargo update --package autocfg --precise 1.1.0should 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.Reacted by tibequadorianSo yeah, seems like gitui and cargo-deny now pass their CI!
Reacted by tranzystorekk and Emi Vasilkovázellij also seems to build locally for aarch64 😄
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
As per cuviper/autocfg#40, autocfg 0.1 versions need to be updated to 0.1.8
Reacted by John ZimmermannAdding 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 }
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.
@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
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.8The 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
Reacted by tranzystorekk and classabbyampYeah, this should be fine to close now that there's a general solution.
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:
Packages with open PRs:
Fixed packages: