[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 [1].
>>>>>
>>>>
>>>> I don't think that this problem is armel related. The error message from
>>>> [1] indicates "Extra }, or forgotten $." when building the documentation
>>>> and the release notes for 0.1.1 from [2] mention "Markup fixes in the
>>>> documentation ". It seems to me that these two issues may very well be
>>>> realated.
>>>> 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.
>>>>
>>>> Regards
>>>>
>>>> Stefan Peter
>>>>
>>>> [1]
>>>> https://buildd.debian.org/status/fetch.php?pkg=freefoam&arch=armel&ver=0.1.0%2Bdfsg-1&stamp=1345145759
>>>> [2] 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.
>>>
>>> Michael
>>>
>>
>> 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.


Michael


Reply to: