This is a partial revert of b1f81b837f
The ARMv8 aarch32 variant specifies a number of required and optional
components. NEON is a required component of ARMv8 devices so we don't
need the 'n' variant that was added in ARMv7 (and never widely used due
to problems). The 'c' crypto variant shouldn't be added. The use of
the crypto extensions to by ARMv8 HW is many and varied and there's no
means of dealing with it at a package/compile extention so the detection
and use of it is done at runtime and handled via a number of different
mechanisms whether in code or via kernel crypto modules and the use of
libkcapi allowing the device to choose the fastest crypto option for
the use case.
This is actively breaking Fedora and related distributions on newer
generations of hardware actively stopping the actual install of an OS
in some extreme cases. This architecture functionality needs to be
reviewed by the architecture maintainers to ensure that active breakage
doesn't happen.
Fixes RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1691430
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
This reverts commit 236d6f5a2b.
This change is fundamentally wrong. arm64 is a catch all that covers the
naming but rpm uses "uname -m" to detect the actual architecture. The aarch64
nonclamenture specifies the ISA (Instruction Set Architecture) for the 64-bit
variant of the Arm architecture which was first supported with ARMv8.
Because all 64-bit variants of ARMv8 use aarch64 the arm64 would never be
used in rpm. If it's useful in some context while using some Debian related
tools those tools should have some translation added there. This just adds
confusion and causes issues and duplication that haven't been necessary in
any of the arch64 work up until now.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
AArch64 has another common name for the architecture: arm64. And while compilers,
the kernel, and RPM use "aarch64", a number of language ecosystems use "arm64".
In addition, Debian packages use the "arm64" architecture name to refer to "aarch64",
and AArch64 packages that are translated from DEB to RPM format tend to not be
installable because there's not a sufficient architecture mapping.
This change adds the "arm64" identifier as an alias for "aarch64" so that this works
as expected, rather than breaking on unknown architectures.
Read presence of relevant extensions from hwcap. Loosely based on what's
currently in use for Fedora (armv7hl) and Pidora (armv6hl).
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Overriding architecture default ABI is not something rpm upstream
should do, such decisions belong to distro level.
- -fsigned-char was originally added in back in 1997 with little
fanfare in commit 3cb5b141d5, for
whatever it is worth...
IBM recently announced the OpenPOWER Consortium, part of this initiative
means now powerpc hardware can run the little endian mode. Create a new
platform for that mode of opperation.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Here is my updated patch adding AArch64 support. The main change was to
use CANONCOLOR=3 rather than 2.
--Mark
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Some vendors insist on calling their x86_64 packages "em64t" instead
of the more standard x86_64. Minimally support this naming convention
as those packages aren't going away anytime soon - be liberal in
what you accept and all, sigh.
- For example, warn when building an x86_64 package that only contains 32
bit binaries.
- This should indicate to the maintainers that they might have gotten the
architecture wrong.
- Introduces 'archcolor' in rpmrc so we can map architectures to colors.
- Related: RhBug:713323
zhangwenlong