scryer-prolog
scryer-prolog copied to clipboard
Build fails on 32-bit systems
While attempting to build scryer in CI, the build for i686 failed. Here's the error I encountered:
error[E0080]: evaluation of constant value failed
--> src/atom_table.rs:22:1
|
22 | const_assert!(mem::size_of::<Atom>() == 8);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to compute `0_usize - 1_usize`, which would overflow
|
= note: this error originates in the macro `const_assert` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0080]: evaluation of constant value failed
--> src/arena.rs:459:1
|
459 | const_assert!(mem::size_of::<AllocSlab>() == 16);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to compute `0_usize - 1_usize`, which would overflow
|
= note: this error originates in the macro `const_assert` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0080`.
This brought me to the following line of code: https://github.com/mthom/scryer-prolog/blob/master/src/atom_table.rs#L22. This prohibits building on 32-bit systems due to the smaller usize. Is this intentional because there are parts of scryer that don't work on 32-bit systems?
Scryer needs 64 bits for its representation of WAM cells, see for example: https://github.com/mthom/scryer-prolog/issues/908#issuecomment-821434998
If the representation needs to be 64 bits, is there a reason it can't use u64
instead of usize
?
If that makes it possible to use Scryer Prolog on 32-bit systems, and at the same time has no significant performance downsides on 64-bit systems, then I think this would be an awesome solution!
there would be no effect, probably, because usize
is a u64
already on 64-bit systems
Scryer's memory management needs 64 bits to represent a WAM cell, so it needs u64
in all systems where we want it to run. On 32-bit systems, usize
is u32
, so using usize
does not work there, even though it coincidentally works on 64-bit systems.
Right, so switching usize to u64 would incur no penalty to existing 64bit and have the added benefit of supporting 32bit
@rujialiu has impressively resolved this via #1972, could you please try it, and if possible re-enable the 32-bit target (https://github.com/void-linux/void-packages/pull/37478) and close this issue if this now works for you? Thank you a lot!
I can confirm this has been fixed in the latest release due to the incredible efforts of @rujialiu; build logs in this PR: https://github.com/void-linux/void-packages/pull/45861. Also, since this project no longer depends on gmp, we were able to enable crossbuilds. Closing now, thank you again!