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

Seth Hetu seth.hetu at gmail.com
Tue Jun 25 18:25:37 PDT 2013


Ok, modifying  fbrt0.c in two places works:

#if defined(HOST_ANDROID) || defined(HOST_DARWIN) || 1

and:

#if !defined(HOST_ANDROID) && !defined(HOST_DARWIN) && 0

Finally, here's that error I was talking about:

ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred

I'm off to scrounge through crosstool-ng's docs for a while. Let me
know if you have any other requests for the Pi binary.

-->Seth



On Tue, Jun 25, 2013 at 4:49 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:
> Hurrah!
>
> Are you going to try modifying fbrt0.c? Does audio and everything seem to work?
>
> Come to think of it, fbgfx should compile for Raspberry Pi and gfx_fb
> should work, since it's just GNU/Linux with X11. Not that we would
> want to use gfx_fb, but I'd be interested in testing fbgfx. I guess I
> could try compiling it myself. Oh, wait, I think it does contain a
> bunch of x86 for accelerated blitting, but I've no idea whether that's
> optional. So don't bother mucking around with that for now.
>
> On 25 June 2013 13:51, Seth Hetu <seth.hetu at gmail.com> wrote:
>> 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
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org



More information about the Ohrrpgce mailing list