[fedora-arm] Setting host system type on ARMv5

[Gordan Bobic]

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 at 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 at 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