[Ohrrpgce] GAME compiles on the RPi, but needs serious debugging.

[Ralph Versteegen]

On 25 June 2013 09:57, Seth Hetu <seth.hetu at gmail.com> wrote:
> Hey all,
>
>    I got GAME to cross-compile for the Raspberry Pi, and cataloged my
> approach here:
>    http://rpg.hamsterrepublic.com/ohrrpgce/Talk:Compiling_for_Android#First_Successful_Build_with_RPi
>
>    Unfortunately, after loading a few libraries and making a few
> function calls it just hangs forever. Strace and ltrace here:
>     http://pastebin.com/bp8nND16
>     http://pastebin.com/N1GjRt0E
>
>     I will now be going through these traces and trying to debug this,
> but I thought a few more pairs of eyes wouldn't hurt. Also, if
> anything in my build steps looks suspicious, please let me know.
> Finally, if any of you encountered a similar "stalling" bug while
> porting to Android, do provide some insight.
>
>     Let's hope we're only a short debug away from a working copy of
> GAME on the RPi!

Yes, in fact this freeze is probably the same as what I experienced on
Android (though I looked at a backtrace, not an strace, so I don't
know if it's identical). The problem was that a futex lock froze
because the futex was never properly initialised by rtlib, because
rtlib's initialisation routine wasn't run. Have a look in
fbc/src/rtlib/static/fbrt0.c. The defined(HOST_ANDROID) ||
defined(HOST_DARWIN) constructor declaration is the portable version,
and should be used on all ARM too. I have no idea why the FB devs
opted to use a nonportable __attribute__((section)) method.

Another way to diagnose this to try replacing -lfbmt in CXXLINKFLAGS
with -lfb. This will link with the non-multithreading build of rtlib,
which doesn't use futexs. In fact, we only use a thread when using
gfx_fb or gfx_alleg backends, so this should be safe to use (but
obviously should be fixed anyway).

> -->Seth
> PS: For those of you wondering, a chroot (or kvm) install won't work
> solely because fbc can't be compiled as a native ARM app (to my
> knowledge). So cross-compiling seems the only way to go.

To compile fbc as an ARM app you need to use -gen gcc (the C emitter).
I haven't tried this myself. Last I heard (a couple months ago), this
either didn't work or didn't produce a working fbc. At least back then
there were still lots of bugs in FB's C emitter (I simply worked
around them).