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.
Peter
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
