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

[Seth Hetu]

And here's a binary:
https://docs.google.com/file/d/0B1P7NepPcOslTW84MEhxRUpCbk0/edit

If you apt-get all of the dependencies (on the Pi, of course), this
will work as-is.

-->Seth

On Mon, Jun 24, 2013 at 9:47 PM, Seth Hetu <seth.hetu at gmail.com> wrote:
> 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