[fedora-arm] Setting host system type on ARMv5

[Jon Masters]

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

I'll ping you and others later about fixing this. Got to finish this
article on atomics now. When I'm done, we should have material others
can use to help fix issues. Not this issue, this isn't really an atomics
issue as it turns out.

Jon.