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(a)redhat.com>
> 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(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.
>>
>> 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.
d.marlin
==========
Gordan
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm