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(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.
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