Peter Robinson <pbrobinson@xxxxxxxxx> wrote:
>On Mon, Jul 30, 2012 at 8:26 AM, Jon Masters <jonathan@xxxxxxxxxxxxxx>
>wrote:
>> On 07/30/2012 03:13 AM, Peter Robinson wrote:
>>> On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters
><jonathan@xxxxxxxxxxxxxx> wrote:
>>>> Folks,
>>>>
>>>> In general, we probably want to look at the value of host system
>type
>>>> being picked up for ARMv5 builds, especially on ARMv7 builder
>systems.
>>>> Here's an example output from running an OpenMPI build on Fedora 18
>>>> using the current Koji builder setup, note the "armv7l" target:
>>>>
>>>> --- begin quote ---
>>>> checking build system type... armv7l-unknown-linux-gnueabi
>>>> checking host system type... armv7l-unknown-linux-gnueabi
>>>> checking target system type... armv7l-unknown-linux-gnueabi
>>>> --- end quote ---
>>>>
>>>> I believe that this is incorrect, at least, this is in question.
>The
>>>> compiler options (set elsewhere) are correct from an ABI point of
>view,
>>>> and the output will be a soft float ABI target, but it's not the
>right
>>>> architecture revision target. It will matter in a few cases. For
>example
>>>> when a package is choosing inline assembly or other specifics that
>>>> differ between ARMv5 and ARMv7. Mostly, we've been lucky in that
>the
>>>> differences are small, but I suspect hidden breakage is lurking.
>>>>
>>>> In this specific example, OpenMPI should move to the new GCC
>atomics
>>>> stuff in due course, but they have a giant mess called "asmlib"
>that
>>>> provides their own custom atomic functions (what could go wrong?)
>for
>>>> historical reasons. The macros used to build that are enough to
>make you
>>>> gouge your eyes out, but once you figure it out, it's obvious that
>they
>>>> do already have ARMv5 assembly code that should work, if it thinks
>it's
>>>> building for an armv5l system. And it's faster to just pick that up
>than
>>>> reworking a lot of not just code, but also other arches and build
>>>> macros, and other stuff unique to the OpenMPI atomics setup.
>>>>
>>>> Let's ponder how we're going to fix it. I could be wrong, but I'd
>think
>>>> we want to ensure that configure is picking up
>>>> armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It
>>>> should do this irrespective of the actual host architecture of the
>>>> builder. I tried just force overriding it in a test build with an
>>>> "%{ifarch} armv5tel" but that wasn't picked up, so I missed
>something,
>>>> but in general that's not the right approach anyway. We want
>something
>>>> at the r-r-c level.
>>>>
>>>> Comments? Dennis? Peter?
>>>
>>> It should always take the details that the build system is telling
>it
>>> and not the underlying platform without exception. The same goes
>with
>>> features like NEON (and MMX/SSE on x86). I've fixed a number of
>these
>>> before.
>>
>> Good. Then you agree it should be thinking
>armv5l-redhat-linux-gnueabi
>> there and this is a bug we need to fix. If we figure out why this is
>> happening, OpenMPI should just build. Meanwhile, if you do setup a
>> "wimpybuilder" channel for v5-specific builds, you could add OpenMPI
>> into that channel and it ought to build if the host is ARMv5. I also
>> thinking we could do something to get at least one successful build
>> through by ensuring it runs on a system that is an ARMv5 host. Then
>we'd
>> at least have an openmpi package that had been built as a dep.
>
>Still fails.
>
>http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1020679
>
>Peter
Thanks. It's picking the wrong bits but for a different reason. I'll hack up a v5 builder environment of my own later and fix it. The point is there are two ways to fix openmpi:
1. Make it build the v5 code it has.
2. Remove all of its asmlib and replace with a few lines of C. Easy but it's a large patch to carry and so for this case only 1 is preferable for the moment.
Not online yet. I just woke up briefly and couldn't help reading email. Back in a few hours.
Jon.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
