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

Seth Hetu seth.hetu at gmail.com
Mon Jun 24 17:33:43 PDT 2013


Ah, thanks for the futex advice; that looks like it might be the
culprit. More details to follow!

-->Seth

On Mon, Jun 24, 2013 at 8:27 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
> 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).
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org



More information about the Ohrrpgce mailing list