emoon / rust_minifb

Cross platfrom window and framebuffer crate for Rust
MIT License
1.04k stars 97 forks source link

compile error on ARM 32 / 64bit #211

Closed derpeter closed 4 years ago

derpeter commented 4 years ago

I try to use minifb on ARM (pi zero 32bit raspberrypiOS arm-linux-gnueabihf / allwinner a64 64bit armbian stable-aarch64-linux-gnu). I tried both current rust stable as well as nightly. Compiling the same git revision with the same toolchain version on 64bit AMD 64 works fine.

The error is

error[E0308]: mismatched types --> src/os/posix/x11.rs:424:52 424 (d.lib.XInternAtom)(d.display, "_MOTIF_WMHINTS\0" as *const as *const i8, 0); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected u8, found i8
= note: expected raw pointer `*const u8`
           found raw pointer `*const i8`

I'm actually not sure if this is a rust bug or minifb bug. As both, i8 and u8 have a platform independent size it should not matter, should it?

emoon commented 4 years ago

Well it's not a Rust bug. Rust is very strict about types and will not cast types silently so you have to be explicit. In this case it looks like the the XInternAtom API takes a *const i8 on ARM/32-bit and *const u8 on x64. I'm not really sure why that is the case. If possible have a look at the XInternAtom API (which I guess is from some x11 crate) and see if it happens to differ for ARM/32-bit for soe reason.

derpeter commented 4 years ago

@emoon https://github.com/erlepereira/x11-rs/blob/9c0b9e5a097515f7b8eccec7d71c5fb749100784/src/xlib.rs#L356 so it seems to use an c_int https://doc.rust-lang.org/std/os/raw/type.c_int.html

My rust is not yet strong enough to understand the mechanics here to tell from where this problems originates.

emoon commented 4 years ago

ok, my guess here is that c_char is set to u8 on ARM/32-bit then while i8 on x64. Which is kinda weird, this is easy to fix. If you can try to change the code above to use as *const _ as *const std::os::raw::c_char instead and see if it works. If it seems to be fine it would be great if you could create a PR for that change.

derpeter commented 4 years ago

thanks for the quick response, PR is there. Linter is unhappy but as far as i can tell its not related to this change but that it can't use nightly features

emoon commented 4 years ago

Linter seems to want to split the line because it got too long

             if opts.borderless {
-                let hints_property =
-                    (d.lib.XInternAtom)(d.display, "_MOTIF_WM_HINTS\0" as *const _ as *const std::os::raw::c_char, 0);
+                let hints_property = (d.lib.XInternAtom)(
+                    d.display,
+                    "_MOTIF_WM_HINTS\0" as *const _ as *const std::os::raw::c_char,
+                    0,
+                );
emoon commented 4 years ago

You can either change it to the code above or add a use std::os::raw::c_char at the top and then use c_char in this code instead.

derpeter commented 4 years ago

thanks for your patience. Pull request is updated, linter is happy.

emoon commented 4 years ago

Great! Thanks for the fix. I don't think anyone has tested minifb (that I know of at least) on RPI before. Is it working as expected?

derpeter commented 4 years ago

We will see. I try to use https://github.com/redox-os/orbtk which uses minifb. So far i have no test code as i could not compile it :-)

So far i can confirm the examples run on armbian on allwinner A64 bit. Pi needs some time to compile also i need to setup x their i guess

derpeter commented 4 years ago

Here you go, the menu example on an plane xserver running on RPI 0 32bit on an 240x240 screen :-) IMG_20200903_184028

emoon commented 4 years ago

nice :)

emoon commented 4 years ago

0.19 has now been released with this fix included.