[Rpm-maint] AArch64 support

Panu Matilainen pmatilai at laiskiainen.org
Tue Feb 26 16:36:45 UTC 2013

On 02/20/2013 08:48 PM, Mark Salter wrote:
> On Wed, 2013-02-20 at 17:14 +0100, Michael Schroeder wrote:
>> On Wed, Feb 20, 2013 at 09:14:54AM -0500, Mark Salter wrote:
>>> On Fri, 2013-02-15 at 12:44 +0200, Panu Matilainen wrote:
>>>> Hi,
>>>> Sorry for the late response, this has gotten buried in the rather
>>>> unusual flood of mail and patches of late...
>>>> On 01/29/2013 10:36 PM, Mark Salter wrote:
>>>>> Here is a patch which adds support for AArch64 architecture. This is
>>>>> just basic support and further support (i.e. auxv parsing) may be desired.
>>>>> It is pretty straightforward except for the hunk in installplatform which
>>>>> sets LIB=${LIB}64. The existing test does this for linux and CANONCOLOR 3.
>>>>> Aarch64 is CANONCOLOR 2, but still wants to use lib64 for the libdir.
>>>> Hmm, aarch64 is not a "multilib architecture"? Or is it just to keep
>>>> things simple by not allowing multilib despite the hardware being
>>>> capable of it? (I'm mostly just curious, but also related to the libdir
>>>> thing)
>>> Honestly, I'm looking at it from a Fedora perspective where the decision
>>> was made to not support multilib for AArch64. AArch64 h/w may be able to
>>> support 32-bit armv8 (AArch32) execution, so non-Fedora folk may have
>>> different opinions about multilib.
>> But isn't it enough to don't include aarch32 in the arch_compat list?
>> Why also mess with canoncolor?
> The patch I posted was mostly the result of cloning ia64 bits because
> ia64 was 64-bit only even though it could support ia32. But leaving that

Like Bill noted, ia64 is only a good example of how NOT to do things :)

> aside, let's say we use canoncolor=3 for aarch64. It doesn't look like
> arch_compat would help in excluding aarch32. Maybe _transaction_color?

The CANONCOLOR value is used for _transaction_color, which is the thing 
that enables the "multilib mode" of rpm which makes it possible to have 
64bit and 32bit packages of same name parallel-installed. However as 
long as you dont specify any 32bit architectures in arch_compat, it has 
practically zero effect on anything [*].

So if aarch64 is indeed multilib-capable hardware (and using lib64 kinda 
hints at that too), CANONCOLOR=3 would seem like the right thing to do: 
it seems more correct technically and avoids having to special-case 
aarch64 from everything else "just because" :)

[*] In old rpm versions, _transaction_color had the, erm, fairly drastic 
effect of practically disabling the arch_compat checking - if the color 
bits matched, it was good to go... but that's no longer the case.

	- Panu -

More information about the Rpm-maint mailing list