Error when cross-building num-bigint


I am trying to cross-build librespot using yocto (using the meta-rust layer) for arm.
Building fails on crate num-bigint-0.2.2 with stuff like:

error[E0407]: method to_i128 is not a member of trait ToPrimitive
error[E0407]: method to_u128 is not a member of trait ToPrimitive
error[E0407]: method from_i128 is not a member of trait FromPrimitive

I tried it with rust 1.37 and 1.36. Both result in the same error.

Building librespot on an actual arm or x64 machine seems to work.

Any ideas on how to get this cross-build succeed?

The errors occur in methods guarded by #[cfg(has_i128)].

Is there a way to specify to the compiler that has_i128 is not true?

I'm not sure how yocto works, but it might be hitting the autocfg issue with RUSTFLAGS solved here:

There's a small compatibility problem remaining in that PR, but I'll try to wrap that up.

Neither am I. Nor do I know much about rust and cargo.

Am I right to think it is possible to override 'rustflags' with an environment var RUSTFLAGS?
If so what should that flag contain to have ' has_i128' become false?

To me it looks like the native crosscompiler does not support i128 for its arm target but still tries to compile it .

There was also an issue that num-traits and num-bigint detected 128-bit support in different ways. I think if you can update to num-bigint 0.2.3, they should be consistent, and that may be good enough for you.

I think I tried to add 0.2.3 to the list of crates that cargo should build. This list is part of the yocto recipe. Unfortunately one of the crates insists of 0.2.2 so cargo complains and does not start the build.

Thanks a lot for your responses. Some time ago I had problems with building rust on OBS (build server for sailfishos). You then also tried to help. In the end I gave up on it and now I am trying the yocto route. Buidling rustc and cargo seems to work (the crosscompilers anyway). Hopefully the rest as well if this i128 thing is handled.

You may have to edit the recipe for those other crates to use 0.2.3.

I just published autocfg 0.1.7 using RUSTFLAGS, which should hopefully be a better fix. But it's the same story for you -- you'll have to make sure that new version is used everywhere in your build.

I modified the recipe to use num-bigint 0.2.3. Also had to delete librespots Cargo.lock to have cargo accept this version.

Now the same problem seems to occur for extprim (1.7.0) which uses #[cfg(extprim_has_stable_i128)].

I should have read your messages better. After modifying the recipe to use autocfg 0.1.7 building now works. Thanks a lot!

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.