Jon Masters 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.
Just for clarification, are you saying that something is not being set
correctly (in rpmmacros, etc.) in the v5 mock chroot when v5 builds are
being run on a v7 host?
Thanks,
d.marlin
=========
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.
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
