2002-03-25 23:16:26 +03:00
#/*! \page config_rpmrc Default configuration: /usr/lib/rpm/rpmrc
# \verbatim
#
#
# This is a global RPM configuration file. All changes made here will
# be lost when the rpm package is upgraded. Any per-system configuration
# should be added to /etc/rpmrc, while per-user configuration should
# be added to ~/.rpmrc.
#
#############################################################
# Values for RPM_OPT_FLAGS for various platforms
2012-12-22 18:57:30 +04:00
optflags: i386 %optflags_default -march=i386 -mtune=generic
optflags: i486 %optflags_default -march=i486 -mtune=generic
optflags: i586 %optflags_default -march=i586 -mtune=generic
optflags: i686 %optflags_default -march=i686 -mtune=generic
2012-12-22 19:02:31 +04:00
optflags: pentium2 %optflags_default -march=pentium2 -mtune=generic
optflags: pentium3 %optflags_default -march=pentium3 -mtune=generic
optflags: pentium4 %optflags_default -march=pentium4 -mtune=generic
optflags: k6 %optflags_default -march=k6 -mtune=generic
optflags: athlon %optflags_default -march=athlon -mtune=generic
optflags: athlon_xp %optflags_default -march=athlon-xp -mtune=generic
2005-06-16 20:18:15 +04:00
optflags: amd64 %optflags_default
2002-03-26 01:32:55 +03:00
optflags: ia64 %optflags_default
2006-03-20 04:18:49 +03:00
optflags: ia32e %optflags_default
2005-06-16 20:18:15 +04:00
optflags: x86_64 %optflags_default
2005-10-10 19:30:58 +04:00
optflags: noarch %optflags_default
2002-03-25 23:16:26 +03:00
2018-03-26 20:39:57 +03:00
# mcst suggests -O3 instead of our default -O2; do that uncoditionally
# !!! changeme for lcc-1.23: -mcpu -> -march !!!
optflags: e2k %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-v3
optflags: e2kv4 %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-v4
optflags: e2kv5 %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-v5
optflags: e2kv6 %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-v6
# !!! changeme for lcc-1.23: -mcpu -> -mtune !!!
optflags: e2k4c %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-4c
optflags: e2k8c %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-8c
optflags: e2k1cp %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-1cp
optflags: e2k8c2 %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-8c2
optflags: e2k12c %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-12c
optflags: e2k16c %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-16c
optflags: e2k2c3 %optflags_core %optflags_warnings -Wno-error %optflags_debug %optflags_optimization -mcpu=elbrus-2c3
2006-03-20 04:18:49 +03:00
# The official RPM starting with 3.0.5 uses -mieee on Alpha by default.
# We don't as to not kill floating-point performance, but packages which
# care might want to add that flag themselves.
optflags: alpha %optflags_default -march=ev4
optflags: alphaev5 %optflags_default -march=ev5
optflags: alphaev56 %optflags_default -march=ev56
optflags: alphapca56 %optflags_default -march=pca56
optflags: alphaev6 %optflags_default -march=ev6
optflags: alphaev67 %optflags_default -march=ev67
optflags: sparc %optflags_default -m32 -mcpu=v8 -mtune=ultrasparc
optflags: sparcv8 %optflags_default -m32 -mcpu=v8 -mtune=ultrasparc
optflags: sparcv9 %optflags_default -m32 -mcpu=ultrasparc
optflags: sparc64 %optflags_default -m64 -mcpu=ultrasparc
optflags: m68k %optflags_default -fomit-frame-pointer
optflags: ppc %optflags_default -fsigned-char
optflags: ppciseries %optflags_default -fsigned-char
optflags: ppcpseries %optflags_default -fsigned-char
optflags: ppc64 %optflags_default -fsigned-char
2018-12-01 16:10:26 +03:00
optflags: ppc64le %optflags_default
2006-03-20 04:18:49 +03:00
optflags: parisc %optflags_default -mpa-risc-1-0
optflags: hppa1.0 %optflags_default -mpa-risc-1-0
optflags: hppa1.1 %optflags_default -mpa-risc-1-0
optflags: hppa1.2 %optflags_default -mpa-risc-1-0
optflags: hppa2.0 %optflags_default -mpa-risc-1-0
optflags: mips %optflags_default
optflags: mipsel %optflags_default
2017-11-17 17:43:56 +03:00
optflags: mipsn32 %optflags_default
optflags: mipsn32el %optflags_default
optflags: mips64 %optflags_default
optflags: mips64el %optflags_default
2006-03-20 04:18:49 +03:00
2007-09-10 11:50:18 +04:00
optflags: armv3l %optflags_default -fomit-frame-pointer -march=armv3
optflags: armv4l %optflags_default -fomit-frame-pointer -march=armv4
optflags: armv5l %optflags_default -fomit-frame-pointer -march=armv5
2008-08-23 17:43:12 +04:00
optflags: armv5tel %optflags_default -fomit-frame-pointer -march=armv5te
optflags: armv5tejl %optflags_default -fomit-frame-pointer -march=armv5te
2010-09-20 16:50:17 +04:00
optflags: armv6l %optflags_default -fomit-frame-pointer -march=armv6
2012-08-05 18:34:32 +04:00
optflags: arm %optflags_default -fomit-frame-pointer -march=armv5te
2016-03-10 18:04:32 +03:00
optflags: armv7l %optflags_default -fomit-frame-pointer -march=armv7-a -mthumb
optflags: armh %optflags_default -fomit-frame-pointer -march=armv7-a -mthumb
2020-07-02 17:30:15 +03:00
optflags: armv8l %optflags_default -fomit-frame-pointer -march=armv8-a -mthumb
2014-10-10 20:47:03 +04:00
optflags: aarch64 %optflags_default
2017-11-17 17:43:56 +03:00
optflags: riscv64 %optflags_default
2022-11-09 17:37:49 +03:00
optflags: loongarch64 %optflags_default
2006-03-20 04:18:49 +03:00
optflags: atarist %optflags_default -fomit-frame-pointer
optflags: atariste %optflags_default -fomit-frame-pointer
optflags: ataritt %optflags_default -fomit-frame-pointer
optflags: falcon %optflags_default -fomit-frame-pointer
optflags: atariclone %optflags_default -fomit-frame-pointer
optflags: milan %optflags_default -fomit-frame-pointer
optflags: hades %optflags_default -fomit-frame-pointer
optflags: s390 %optflags_default
optflags: s390x %optflags_default
2002-03-25 23:16:26 +03:00
#############################################################
# Canonical arch names and numbers
2004-10-31 22:08:39 +03:00
arch_canon: pentium4: pentium4 1
2006-03-20 04:18:49 +03:00
arch_canon: pentium3: pentium3 1
arch_canon: pentium2: pentium2 1
2006-09-17 01:50:43 +04:00
arch_canon: athlon_xp: athlon_xp 1
2002-03-25 23:16:26 +03:00
arch_canon: athlon: athlon 1
arch_canon: i686: i686 1
2002-03-26 01:32:55 +03:00
arch_canon: k6: k6 1
2002-03-25 23:16:26 +03:00
arch_canon: i586: i586 1
arch_canon: i486: i486 1
arch_canon: i386: i386 1
2005-06-16 20:18:15 +04:00
arch_canon: amd64: amd64 1
arch_canon: ia32e: ia32e 1
2006-03-20 17:50:02 +03:00
arch_canon: x86_64: x86_64 1
2002-03-25 23:16:26 +03:00
arch_canon: alpha: alpha 2
arch_canon: alphaev5: alphaev5 2
arch_canon: alphaev56: alphaev56 2
arch_canon: alphapca56:alphapca56 2
arch_canon: alphaev6: alphaev6 2
arch_canon: alphaev67: alphaev67 2
arch_canon: sparc: sparc 3
arch_canon: sun4: sparc 3
arch_canon: sun4m: sparc 3
arch_canon: sun4c: sparc 3
arch_canon: sun4d: sparc 3
2006-03-20 04:18:49 +03:00
arch_canon: sparcv8: sparcv8 3
2002-03-25 23:16:26 +03:00
arch_canon: sparcv9: sparcv9 3
# This is really a place holder for MIPS.
arch_canon: mips: mips 4
arch_canon: ppc: ppc 5
arch_canon: ppciseries: ppciseries 5
arch_canon: ppcpseries: ppcpseries 5
arch_canon: m68k: m68k 6
arch_canon: IP: sgi 7
arch_canon: rs6000: rs6000 8
arch_canon: ia64: ia64 9
arch_canon: sparc64:sparc64 10
arch_canon: sun4u: sparc64 10
2017-11-17 17:43:56 +03:00
2002-03-25 23:16:26 +03:00
arch_canon: mipsel: mipsel 11
2017-11-17 17:43:56 +03:00
arch_canon: mipsn32: mipsn32 11
arch_canon: mipsn32el: mipsn32el 11
arch_canon: mips64: mips64 11
arch_canon: mips64el: mips64el 11
2002-03-25 23:16:26 +03:00
2007-04-08 00:55:46 +04:00
arch_canon: armv4b: armeb 12
rpmrc.in: inessential tweaks to follow upstream rpmrc.in more closely
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
2020-07-02 20:56:19 +03:00
arch_canon: armv5b: armeb 12
arch_canon: armv3l: armv3l 12
arch_canon: armv4l: arm 12
arch_canon: armv5l: armv5l 12
arch_canon: armv5tel: armv5tel 12
arch_canon: armv5tejl: armv5tejl 12
arch_canon: armv6l: arm 12
arch_canon: armh: armh 12
arch_canon: armv7l: armv7l 12
arch_canon: armv8l: armv8l 12
2002-03-25 23:16:26 +03:00
arch_canon: m68kmint: m68kmint 13
arch_canon: atarist: m68kmint 13
arch_canon: atariste: m68kmint 13
arch_canon: ataritt: m68kmint 13
arch_canon: falcon: m68kmint 13
arch_canon: atariclone: m68kmint 13
arch_canon: milan: m68kmint 13
arch_canon: hades: m68kmint 13
arch_canon: s390: s390 14
arch_canon: i370: i370 14
arch_canon: s390x: s390x 15
arch_canon: ppc64: ppc64 16
2018-12-01 16:10:26 +03:00
arch_canon: ppc64le: ppc64le 16
2002-03-25 23:16:26 +03:00
2006-03-20 04:18:49 +03:00
arch_canon: sh: sh 17
arch_canon: xtensa: xtensa 18
2014-10-10 20:47:03 +04:00
arch_canon: aarch64: aarch64 19
2018-03-26 20:39:57 +03:00
arch_canon: e2k: e2k 23
arch_canon: e2kv4: e2kv4 23
arch_canon: e2kv5: e2kv5 23
arch_canon: e2kv6: e2kv6 23
arch_canon: e2k4c: e2k4c 23
arch_canon: e2k8c: e2k8c 23
arch_canon: e2k1cp: e2k1cp 23
arch_canon: e2k8c2: e2k8c2 23
arch_canon: e2k12c: e2k16c 23
arch_canon: e2k2c3: e2k2c3 23
2022-11-09 17:37:49 +03:00
# XXX: Upstream sets this to 23, but we have e2k:
arch_canon: loongarch64: loongarch64 24
2002-03-25 23:16:26 +03:00
#############################################################
# Canonical OS names and numbers
os_canon: Linux: Linux 1
os_canon: IRIX: Irix 2
# This is wrong
os_canon: SunOS5: solaris 3
os_canon: SunOS4: SunOS 4
os_canon: AmigaOS: AmigaOS 5
os_canon: AIX: AIX 5
os_canon: HP-UX: hpux10 6
os_canon: OSF1: osf1 7
os_canon: osf4.0: osf1 7
os_canon: osf3.2: osf1 7
os_canon: FreeBSD: FreeBSD 8
os_canon: SCO_SV: SCO_SV3.2v5.0.2 9
os_canon: IRIX64: Irix64 10
os_canon: NEXTSTEP: NextStep 11
os_canon: BSD_OS: bsdi 12
os_canon: machten: machten 13
os_canon: CYGWIN32_NT: cygwin32 14
os_canon: CYGWIN32_95: cygwin32 15
os_canon: UNIX_SV: MP_RAS: 16
os_canon: MiNT: FreeMiNT 17
os_canon: OS/390: OS/390 18
os_canon: VM/ESA: VM/ESA 19
os_canon: Linux/390: OS/390 20
os_canon: Linux/ESA: VM/ESA 20
2006-03-20 04:18:49 +03:00
os_canon: Darwin: darwin 21
os_canon: MacOSX: macosx 21
2002-03-25 23:16:26 +03:00
#############################################################
# For a given uname().machine, the default build arch
buildarchtranslate: osfmach3_i686: i386
buildarchtranslate: osfmach3_i586: i386
buildarchtranslate: osfmach3_i486: i386
buildarchtranslate: osfmach3_i386: i386
buildarchtranslate: ia64: ia64
2005-06-16 20:18:15 +04:00
buildarchtranslate: x86_64: x86_64
buildarchtranslate: amd64: x86_64
buildarchtranslate: ia32e: x86_64
2004-10-31 22:08:39 +03:00
buildarchtranslate: pentium4: pentium4
2006-03-20 04:18:49 +03:00
buildarchtranslate: pentium3: pentium3
buildarchtranslate: pentium2: pentium2
2006-09-17 01:50:43 +04:00
buildarchtranslate: athlon_xp: athlon_xp
2002-03-26 01:32:55 +03:00
buildarchtranslate: athlon: athlon
buildarchtranslate: i686: i686
buildarchtranslate: k6: k6
buildarchtranslate: i586: i586
buildarchtranslate: i486: i486
2002-03-25 23:16:26 +03:00
buildarchtranslate: i386: i386
buildarchtranslate: alphaev5: alpha
buildarchtranslate: alphaev56: alpha
buildarchtranslate: alphapca56: alpha
buildarchtranslate: alphaev6: alpha
buildarchtranslate: alphaev67: alpha
buildarchtranslate: sun4c: sparc
buildarchtranslate: sun4d: sparc
buildarchtranslate: sun4m: sparc
2006-03-20 04:18:49 +03:00
buildarchtranslate: sparcv8: sparc
2002-03-25 23:16:26 +03:00
buildarchtranslate: sparcv9: sparc
buildarchtranslate: sun4u: sparc64
buildarchtranslate: osfmach3_ppc: ppc
buildarchtranslate: powerpc: ppc
buildarchtranslate: powerppc: ppc
buildarchtranslate: ppciseries: ppc
buildarchtranslate: ppcpseries: ppc
buildarchtranslate: atarist: m68kmint
buildarchtranslate: atariste: m68kmint
buildarchtranslate: ataritt: m68kmint
buildarchtranslate: falcon: m68kmint
buildarchtranslate: atariclone: m68kmint
buildarchtranslate: milan: m68kmint
buildarchtranslate: hades: m68kmint
buildarchtranslate: s390: s390
buildarchtranslate: s390x: s390x
#############################################################
# Architecture compatibility
arch_compat: alphaev67: alphaev6
arch_compat: alphaev6: alphapca56
arch_compat: alphapca56: alphaev56
arch_compat: alphaev56: alphaev5
arch_compat: alphaev5: alpha
arch_compat: alpha: axp noarch
2006-03-20 04:18:49 +03:00
arch_compat: pentium4: pentium3
2006-09-17 01:50:43 +04:00
arch_compat: athlon_xp: athlon pentium3
2006-03-20 04:18:49 +03:00
arch_compat: pentium3: pentium2
2006-03-20 17:50:02 +03:00
arch_compat: athlon: k6 pentium2
2006-03-20 04:18:49 +03:00
arch_compat: pentium2: i686
2002-03-25 23:16:26 +03:00
arch_compat: i686: i586
2002-03-26 01:32:55 +03:00
arch_compat: k6: i586
2002-03-25 23:16:26 +03:00
arch_compat: i586: i486
arch_compat: i486: i386
arch_compat: i386: noarch
2018-03-26 20:39:57 +03:00
arch_compat: e2k12c: e2kv6
arch_compat: e2k16c: e2kv6
arch_compat: e2k2c3: e2kv6
arch_compat: e2kv6: e2kv5
arch_compat: e2k8c2: e2kv5
arch_compat: e2kv5: e2kv4
arch_compat: e2k8c: e2kv4
arch_compat: e2k1cp: e2kv4
arch_compat: e2kv4: e2k
arch_compat: e2k4c: e2k
arch_compat: e2k: noarch
2002-03-25 23:16:26 +03:00
arch_compat: osfmach3_i686: i686 osfmach3_i586
arch_compat: osfmach3_i586: i586 osfmach3_i486
arch_compat: osfmach3_i486: i486 osfmach3_i386
arch_compat: osfmach3_i386: i486
arch_compat: osfmach3_ppc: ppc
arch_compat: powerpc: ppc
arch_compat: powerppc: ppc
arch_compat: ppciseries: ppc
arch_compat: ppcpseries: ppc
arch_compat: ppc64: ppc
arch_compat: ppc: rs6000
arch_compat: rs6000: noarch
2018-12-01 16:10:26 +03:00
arch_compat: ppc64le: noarch
2002-03-25 23:16:26 +03:00
arch_compat: sun4c: sparc
arch_compat: sun4d: sparc
arch_compat: sun4m: sparc
arch_compat: sun4u: sparc64
arch_compat: sparc64: sparcv9
arch_compat: sparcv9: sparc
2006-03-20 04:18:49 +03:00
arch_compat: sparcv8: sparc
2002-03-25 23:16:26 +03:00
arch_compat: sparc: noarch
arch_compat: mips: noarch
arch_compat: mipsel: noarch
2017-11-17 17:43:56 +03:00
arch_compat: mipsn32: noarch
arch_compat: mipsn32el: noarch
arch_compat: mips64: noarch
arch_compat: mips64el: noarch
2002-03-25 23:16:26 +03:00
arch_compat: hppa2.0: hppa1.2
arch_compat: hppa1.2: hppa1.1
arch_compat: hppa1.1: hppa1.0
arch_compat: hppa1.0: parisc
arch_compat: parisc: noarch
rpmrc.in: inessential tweaks to follow upstream rpmrc.in more closely
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
2020-07-02 20:56:19 +03:00
arch_compat: armv5b: armv4b
arch_compat: armv4b: armeb
arch_compat: armeb: noarch
2012-08-05 18:34:32 +04:00
arch_compat: armv6l: armv5tejl
2008-08-23 17:43:12 +04:00
arch_compat: armv5tejl: armv5tel
arch_compat: armv5tel: armv5l
2010-09-20 16:50:17 +04:00
arch_compat: armv5l: arm
2007-04-08 00:55:46 +04:00
arch_compat: arm: armv3l
2002-03-25 23:16:26 +03:00
arch_compat: armv3l: noarch
rpmrc.in: inessential tweaks to follow upstream rpmrc.in more closely
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
2020-07-02 20:56:19 +03:00
arch_compat: armv8l: armv7l
arch_compat: armv7l: armh
arch_compat: armh: noarch
2002-03-25 23:16:26 +03:00
arch_compat: atarist: m68kmint noarch
arch_compat: atariste: m68kmint noarch
arch_compat: ataritt: m68kmint noarch
arch_compat: falcon: m68kmint noarch
arch_compat: atariclone: m68kmint noarch
arch_compat: milan: m68kmint noarch
arch_compat: hades: m68kmint noarch
arch_compat: i370: noarch
arch_compat: s390: noarch
arch_compat: s390x: s390 noarch
2005-06-16 20:18:15 +04:00
arch_compat: ia64: noarch
2006-03-20 17:50:02 +03:00
arch_compat: amd64: x86_64
arch_compat: ia32e: x86_64
2006-09-17 01:50:43 +04:00
arch_compat: x86_64: athlon_xp pentium4
2002-03-25 23:16:26 +03:00
rpmrc.in: inessential tweaks to follow upstream rpmrc.in more closely
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
2020-07-02 20:56:19 +03:00
arch_compat: aarch64: noarch
2017-11-17 17:43:56 +03:00
arch_compat: riscv64: noarch
2022-11-09 17:37:49 +03:00
arch_compat: loongarch64: noarch
2002-03-25 23:16:26 +03:00
os_compat: IRIX64: IRIX
os_compat: solaris2.7: solaris2.3 solaris2.4 solaris2.5 solaris2.6
os_compat: solaris2.6: solaris2.3 solaris2.4 solaris2.5
os_compat: solaris2.5: solaris2.3 solaris2.4
os_compat: solaris2.4: solaris2.3
os_compat: hpux11.00: hpux10.30
os_compat: hpux10.30: hpux10.20
os_compat: hpux10.20: hpux10.10
os_compat: hpux10.10: hpux10.01
os_compat: hpux10.01: hpux10.00
os_compat: hpux10.00: hpux9.07
os_compat: hpux9.07: hpux9.05
os_compat: hpux9.05: hpux9.04
os_compat: osf4.0: osf3.2 osf1
os_compat: ncr-sysv4.3: ncr-sysv4.2
os_compat: FreeMiNT: mint MiNT TOS
os_compat: MiNT: FreeMiNT mint TOS
os_compat: mint: FreeMiNT MiNT TOS
os_compat: TOS: FreeMiNT MiNT mint
os_compat: BSD_OS: bsdi
os_compat: bsdi4.0: bsdi
2006-03-20 04:18:49 +03:00
os_compat: Darwin: MacOSX
2002-03-25 23:16:26 +03:00
buildarch_compat: ia64: noarch
rpmrc.in: inessential tweaks to follow upstream rpmrc.in more closely
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
2020-07-02 20:56:19 +03:00
buildarch_compat: aarch64: noarch
2005-06-16 20:18:15 +04:00
buildarch_compat: x86_64: noarch
buildarch_compat: amd64: x86_64
buildarch_compat: ia32e: x86_64
2006-03-20 04:18:49 +03:00
buildarch_compat: pentium4: pentium3
2006-09-17 01:50:43 +04:00
buildarch_compat: athlon_xp: athlon pentium3
2006-03-20 04:18:49 +03:00
buildarch_compat: pentium3: pentium2
2006-03-20 17:50:02 +03:00
buildarch_compat: athlon: k6 pentium2
2006-03-20 04:18:49 +03:00
buildarch_compat: pentium2: i686
2002-03-25 23:16:26 +03:00
buildarch_compat: i686: i586
2002-03-26 01:32:55 +03:00
buildarch_compat: k6: i586
2002-03-25 23:16:26 +03:00
buildarch_compat: i586: i486
buildarch_compat: i486: i386
buildarch_compat: i386: noarch
2018-03-26 20:39:57 +03:00
buildarch_compat: e2k12c: e2kv6
buildarch_compat: e2k16c: e2kv6
buildarch_compat: e2k2c3: e2kv6
buildarch_compat: e2kv6: e2kv5
buildarch_compat: e2k8c2: e2kv5
buildarch_compat: e2kv5: e2kv4
buildarch_compat: e2k8c: e2kv4
buildarch_compat: e2k1cp: e2kv4
buildarch_compat: e2kv4: e2k
buildarch_compat: e2k4c: e2k
buildarch_compat: e2k: noarch
2002-03-25 23:16:26 +03:00
buildarch_compat: sun4c: noarch
buildarch_compat: sun4d: noarch
buildarch_compat: sun4m: noarch
buildarch_compat: sun4u: noarch
buildarch_compat: sparc64: noarch
buildarch_compat: sparcv9: sparc
buildarch_compat: sparc: noarch
buildarch_compat: alphaev67: alphaev6
buildarch_compat: alphaev6: alphapca56
buildarch_compat: alphapca56: alphaev56
buildarch_compat: alphaev56: alphaev5
buildarch_compat: alphaev5: alpha
buildarch_compat: alpha: noarch
buildarch_compat: m68k: noarch
buildarch_compat: ppciseries: noarch
buildarch_compat: ppcpseries: noarch
buildarch_compat: ppc: noarch
buildarch_compat: ppc64: noarch
2018-12-01 16:10:26 +03:00
buildarch_compat: ppc64le: noarch
2002-03-25 23:16:26 +03:00
buildarch_compat: mips: noarch
buildarch_compat: mipsel: noarch
2017-11-17 17:43:56 +03:00
buildarch_compat: mipsn32: noarch
buildarch_compat: mipsn32el: noarch
buildarch_compat: mips64: noarch
buildarch_compat: mips64el: noarch
2002-03-25 23:16:26 +03:00
rpmrc.in: inessential tweaks to follow upstream rpmrc.in more closely
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
2020-07-02 20:56:19 +03:00
buildarch_compat: armv5b: armv4b
buildarch_compat: armv4b: arrmeb
buildarch_compat: armeb: noarch
2012-08-05 18:34:32 +04:00
buildarch_compat: armv6l: armv5tejl
2008-08-23 17:43:12 +04:00
buildarch_compat: armv5tejl: armv5tel
buildarch_compat: armv5tel: armv5l
2007-04-08 00:55:46 +04:00
buildarch_compat: armv5l: armv4l
buildarch_compat: armv4l: arm
buildarch_compat: arm: armv3l
2002-03-25 23:16:26 +03:00
buildarch_compat: armv3l: noarch
rpmrc.in: inessential tweaks to follow upstream rpmrc.in more closely
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
2020-07-02 20:56:19 +03:00
buildarch_compat: armv8l: armv7l
buildarch_compat: armv7l: armh
buildarch_compat: armh: noarch
2002-03-25 23:16:26 +03:00
buildarch_compat: hppa2.0: hppa1.2
buildarch_compat: hppa1.2: hppa1.1
buildarch_compat: hppa1.1: hppa1.0
buildarch_compat: hppa1.0: parisc
buildarch_compat: parisc: noarch
buildarch_compat: atarist: m68kmint noarch
buildarch_compat: atariste: m68kmint noarch
buildarch_compat: ataritt: m68kmint noarch
buildarch_compat: falcon: m68kmint noarch
buildarch_compat: atariclone: m68kmint noarch
buildarch_compat: milan: m68kmint noarch
buildarch_compat: hades: m68kmint noarch
buildarch_compat: ia64: noarch
buildarch_compat: s390: noarch
buildarch_compat: s390x: noarch
2017-11-17 17:43:56 +03:00
buildarch_compat: riscv64: noarch
2022-11-09 17:37:49 +03:00
buildarch_compat: loongarch64: noarch
2016-06-21 18:37:08 +03:00
macrofiles: @RPMCONFIGDIR@/buildmacros:@RPMCONFIGDIR@/%{_target}/macros:@RPMCONFIGDIR@/macros.d/*:@SYSCONFIGDIR@/macros.specspo:@SYSCONFIGDIR@/macros.cdb:@SYSCONFIGDIR@/macros:@SYSCONFIGDIR@/%{_target}/macros:@SYSCONFIGDIR@/macros.d/*:~/.rpmmacros
2002-03-25 23:16:26 +03:00
# \endverbatim
#*/