On Mon, Jul 30, 2012 at 8:26 AM, Jon Masters <jonathan(a)jonmasters.org> wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
> On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters <jonathan(a)jonmasters.org> 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