scryer-prolog icon indicating copy to clipboard operation
scryer-prolog copied to clipboard

Build fails on 32-bit systems

Open cinerea0 opened this issue 2 years ago • 3 comments

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?

cinerea0 avatar Jun 10 '22 00:06 cinerea0

Scryer needs 64 bits for its representation of WAM cells, see for example: https://github.com/mthom/scryer-prolog/issues/908#issuecomment-821434998

triska avatar Jun 10 '22 08:06 triska

If the representation needs to be 64 bits, is there a reason it can't use u64 instead of usize?

ericonr avatar Jun 10 '22 12:06 ericonr

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!

triska avatar Jun 10 '22 12:06 triska

there would be no effect, probably, because usize is a u64 already on 64-bit systems

classabbyamp avatar Jun 23 '23 17:06 classabbyamp

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.

triska avatar Jun 23 '23 18:06 triska

Right, so switching usize to u64 would incur no penalty to existing 64bit and have the added benefit of supporting 32bit

classabbyamp avatar Jun 23 '23 18:06 classabbyamp

@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!

triska avatar Aug 25 '23 20:08 triska

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!

cinerea0 avatar Sep 01 '23 04:09 cinerea0