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

[Seth Hetu]

MAGIC!

(I used -lfb instead of -lfbmt).

-->Seth

On Mon, Jun 24, 2013 at 8:33 PM, Seth Hetu <seth.hetu at gmail.com> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ohrpi.png
Type: image/png
Size: 120188 bytes
Desc: not available
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20130624/7f61a533/attachment-0002.png>