rpm-build/rpmrc.in

523 lines
17 KiB
Plaintext
Raw Normal View History

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
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
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
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
# 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
# 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
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
optflags: mipsn32 %optflags_default
optflags: mipsn32el %optflags_default
optflags: mips64 %optflags_default
optflags: mips64el %optflags_default
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
optflags: armv5tel %optflags_default -fomit-frame-pointer -march=armv5te
optflags: armv5tejl %optflags_default -fomit-frame-pointer -march=armv5te
optflags: armv6l %optflags_default -fomit-frame-pointer -march=armv6
optflags: arm %optflags_default -fomit-frame-pointer -march=armv5te
optflags: armv7l %optflags_default -fomit-frame-pointer -march=armv7-a -mthumb
optflags: armh %optflags_default -fomit-frame-pointer -march=armv7-a -mthumb
optflags: armv8l %optflags_default -fomit-frame-pointer -march=armv8-a -mthumb
optflags: aarch64 %optflags_default
optflags: riscv64 %optflags_default
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
arch_canon: pentium4: pentium4 1
arch_canon: pentium3: pentium3 1
arch_canon: pentium2: pentium2 1
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
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
2002-03-25 23:16:26 +03:00
arch_canon: mipsel: mipsel 11
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
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
arch_canon: sh: sh 17
arch_canon: xtensa: xtensa 18
arch_canon: aarch64: aarch64 19
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
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
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
buildarchtranslate: pentium4: pentium4
buildarchtranslate: pentium3: pentium3
buildarchtranslate: pentium2: pentium2
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
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
arch_compat: pentium4: pentium3
arch_compat: athlon_xp: athlon pentium3
arch_compat: pentium3: pentium2
2006-03-20 17:50:02 +03:00
arch_compat: athlon: k6 pentium2
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
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
arch_compat: sparcv8: sparc
2002-03-25 23:16:26 +03:00
arch_compat: sparc: noarch
arch_compat: mips: noarch
arch_compat: mipsel: noarch
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
arch_compat: armv6l: armv5tejl
arch_compat: armv5tejl: armv5tel
arch_compat: armv5tel: armv5l
arch_compat: armv5l: arm
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
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
arch_compat: riscv64: 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
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
buildarch_compat: pentium4: pentium3
buildarch_compat: athlon_xp: athlon pentium3
buildarch_compat: pentium3: pentium2
2006-03-20 17:50:02 +03:00
buildarch_compat: athlon: k6 pentium2
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
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
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
buildarch_compat: armv6l: armv5tejl
buildarch_compat: armv5tejl: armv5tel
buildarch_compat: armv5tel: armv5l
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
buildarch_compat: riscv64: noarch
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
#*/