Since neither objections or anything new has come up in all this time, about
time we merged this.
Thanks for the patch and sorry for taking so long.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #425 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/425#event-1876603096___
Rpm-maint mailing list
I should point out some deficiencies in using logic based on the {I,L,P,E} bits.
1) many operations to determine coloring of packages and transactions depend on
the ability of simply or'ing together file color flags contained within.
2) it's not just the insanity of static archives (and
Correction: I meant Itanium IA64, not IA32, as the dinosaur platform that
should burn in hell.
But perhaps there's enough room in hell for ia32 to join its ia64 marketing
named brethren as well ;-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
The critical values for rpm installation are the file color bits, not the ever
evolving arch names.
The color values originally mapped onto the elf 32 and 64 bit designators
because that is all that mattered at the time. The color value was designed as
a bit mask to accomodate the insanity
I think this makes most sense (and is what I implemented in the original patch):
armv8l == old ABI compatible with armv7l
armv8hl == old hardfloat EABI compatible with armv7hl
armv8hnl == armv8hl + neon, compatible with armv7hnl
armv8hcnl == armv8hnl + crypto extensions
ILP32, if properly
@pmatilai someone brought to my attention today there is various confusion as
to what 'armv8' actually means (for a package type).
Does it mean traditional 32-bit ABI using instructions available on an 'ARMv8'
processor?
or does it mean using ILP32 ABI using all of the aarch64 instructions?
My largely uneducated take in this is... how about we just forget the exception
clause about specialized environments and just define armv8 in rpm to mean
standard armv8?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
If you wish to move to "human readable" names, then the specific
functionalities tied to arch in rpmrc need to be separately configured.
There's only a few critical values that rpmrc provides a default for
* (per-arch) optflags (like in this issue)
* (global) macrofiles search patterns
and the
@berolinux Just to be clear, I -have- a customer who has asked for armv8
WITHOUT NEON/VFP. This was obviously in the embedded space, but the same
customer is saying that it's not for compatibility, but is actually a 32-bit
'armv8' processor. (No 64-bit support..) I have no idea if those
@mlschroe aarch64 and armv8 are the same CPU, but (obviously, given one is
32bit and one is 64bit) a different ABI -- no need to carry over the legacy
float ABI.
For neon, all aarch64 CPUs made so far have it, and it is part of the aarch64
core - however, ARM's docs say "Both floating-point
Pardon the dumb question, but if armv8 is just the 32bit mode of aarch64 why
doesn't aarch64 also need those float/neon/crypto modifiers?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@n3npq At least in the arm world it's somewhat less insane: uname -m shows what
it should, armv7 vs armv8 vs aarch64 etc. is 100% consistent across all
processors regardless of manufacturer and marketing names.
--
You are receiving this because you are subscribed to this thread.
Reply to this
berolinux commented on this pull request.
> @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard
> -mfpu=vfp
optflags: armv7l -O2 -g -march=armv7
optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
optflags: armv7hnl -O2 -g -march=armv7-a
History repeats itself with ARM architectures ...
At one point in time (see your favorite VCS for rpm -- git, cvs, whatever)
rpmrc carried entries for i786/i886/I986.
RPM development (IMHO) became impossible when RPM needed to detect a specific
hardware (and buggy!) hardware flashing on PPC by
mhatle commented on this pull request.
> @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard
> -mfpu=vfp
optflags: armv7l -O2 -g -march=armv7
optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
optflags: armv7hnl -O2 -g -march=armv7-a
kwizart commented on this pull request.
> @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard
> -mfpu=vfp
optflags: armv7l -O2 -g -march=armv7
optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
optflags: armv7hnl -O2 -g -march=armv7-a
> armv8* is aarch64 machines in 32-bit mode.
What is aarch32 then ? (open question).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/425#pullrequestreview-108512134___
Conan-Kudo requested changes on this pull request.
Small suggestions.
> @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard
> -mfpu=vfp
optflags: armv7l -O2 -g -march=armv7
optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
optflags: armv7hnl -O2 -g
Conan-Kudo approved this pull request.
Looks good to me! Nice job!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
According to
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CJHECGIH.html,
"Both floating-point and NEON are required in all standard ARMv8
implementations", but "implementations targeting specialized markets may
support the following combinations:
No NEON or
Conan-Kudo commented on this pull request.
> @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard
> -mfpu=vfp
optflags: armv7l -O2 -g -march=armv7
optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
optflags: armv7hnl -O2 -g -march=armv7-a
berolinux commented on this pull request.
> @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard
> -mfpu=vfp
optflags: armv7l -O2 -g -march=armv7
optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
optflags: armv7hnl -O2 -g -march=armv7-a
berolinux commented on this pull request.
> @@ -461,6 +472,8 @@ arch_compat: armv5tl: armv4tl
arch_compat: armv4tl: armv4l
arch_compat: armv4l: armv3l
arch_compat: armv3l: noarch
+arch_compat: armv8hnl: armv8hl
+arch_compat: armv8hl: armv7hnl
Since NEON is mandatory on aarch64, armv8hnl and
Conan-Kudo requested changes on this pull request.
> @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard
> -mfpu=vfp
optflags: armv7l -O2 -g -march=armv7
optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
optflags: armv7hnl -O2 -g -march=armv7-a
Conan-Kudo requested changes on this pull request.
> @@ -461,6 +472,8 @@ arch_compat: armv5tl: armv4tl
arch_compat: armv4tl: armv4l
arch_compat: armv4l: armv3l
arch_compat: armv3l: noarch
+arch_compat: armv8hnl: armv8hl
+arch_compat: armv8hl: armv7hnl
This is not compatible. This does not
27 matches
Mail list logo
