Re: Fwd: Help needed debugging on ARM
On 08/30/2012 06:59 PM, Lennart Sorensen wrote:
> On Thu, Aug 30, 2012 at 10:48:00AM +0200, Michael Wild wrote:
>> On 08/29/2012 11:04 AM, Michael Wild wrote:
>>> On 08/29/2012 10:48 AM, Stefan Peter wrote:
>>>> Hi Michael,
>>>> On 29.08.2012 09:35, Michael Wild wrote:
>>>>> I want to resolve a very strange build failure that is happening on all
>>>>> ARM architectures. The package builds some of its documentation images
>>>>> with asymptote, which fails .
>>>> I don't think that this problem is armel related. The error message from
>>>>  indicates "Extra }, or forgotten $." when building the documentation
>>>> and the release notes for 0.1.1 from  mention "Markup fixes in the
>>>> documentation ". It seems to me that these two issues may very well be
>>>> You may want to build 0.1.1 (or even 0.1.2, released 2012-07-23) in
>>>> order the validate the issue. A diff for the plain_Label.asy file of
>>>> these three versions may shed some light, too.
>>>> Stefan Peter
>>>>  http://freefoam.sourceforge.net/
>>> I only get this errors on ARM, all other architectures are fine. The
>>> "markup-fixes" you mention are related to the asciidoc source, not the
>>> asymptote images.
>> Wow, that's fun. I got the QEMU VM up and running, and guess what. No
>> error! Works just fine. So either it is my setup, the fact that I'm
>> running inside QEMU, or these build failures are sporadic.
>> Could it be a difference in the CPU type? I chose Versatile/PB while the
>> failing buildd for armel (alwyn) is a Marvell Feroceon (Kirkwood?).
>> However, AFAIK, this option is not available with QEMU... What should I use?
>> Any other advice on how I could get to the bottom of this issue?
> Some ARMs have issues with bad data alignment. Others do not. I believe
> qemu also has no issue with bad alignment.
> So if the program happens to fail because of bad alignment, then only
> certain kinds of systems would see it.
That would explain that particular failure. Would splitting of the build
into -arch and -indep help in the sense that the -indep packages only
get built on one architecture? If so, which one would that be?
> Of course it also seems this particular package is failing on almost
> every architecture in some way.
That's my mistake. I simply forgot to take care of the non-Intel
architectures when I ported the upstream project's (OpenFOAM) build
system to CMake. I have those failures fixed already locally, but before
filing an RFS I wanted to get to the bottom of the asymptote-failure...
> Annoyingly it doesn't use parallel build (annoying when you have 24
> threads on 6 cores on a powerpc box with nothing better to do). Also I
> can't help but think there is some serious misuse of doxygen going on
> giving how much time it spends with a python script "fixing" the output
> doxygen made.
Yes, my co-maintainer probably just didn't know about that. I have that
fixed also locally, but don't think it would get past the freeze, right?
The doxygen-fixup is necessary because of the way that OpenFOAM
organizes it's source tree. Doxygen just doesn't seem to like what I did
in FreeFOAM, and thus the output needs patching. Possibly I could speed
it up a lot, I just didn't have the time to look into that.