On 07/30/2012 06:10 PM, David Marlin wrote:
Gordan Bobic wrote:
On 07/30/2012 03:05 PM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 2:53 PM, David A. Marlin<dmarlin@xxxxxxxxxx>
wrote:
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?
No, some projects aren't following the cflags etc as specified in
rpmmacros.
There is quite a lot of that going on. Not only that, but %__cc is
frequently ignored, too, so it isn't as easy as it should be to
rebuild some packages using a different compiler.
Ok, so this is a 'per package' type fix, and not something we can fix in
the build environment.
Thank you Peter and Gordan for the clarification.
I have some bugzilla tickets filed for a few packages where I've found
this happening, but it is by no means exhaustive. I suggest you file a
ticket for each package you find that isn't packaged correctly to obey
the rpm macro conventions.
Gordan
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
