- VFPv3D16 is a specific type of VFP, which AIUI is never a NEON,
so the test made little sense and, AIUI did not work at all, at
least for detecting NEON-class system.
Test for generic VFPv3 support instead (although this doesn't likely
make a whole lot of sense as AIUI all ARMv7 systems are supposed
to come with VFPv3 level VFP but guess it doesn't hurt either...)
- The local define for HWCAP_ARM_VFPv3D16 from commit
5a04330db8 was wrong, (1 << 13) is
actually HWCAP_ARM_VFPv3. Which is of course exactly what we want here,
but the commit looks fishy because of this.
- This is all just sooooo wonderfully arbitrary...
- If you dont know, you'll want to keep it that way.
However if you know this is wrong, let me know...
- If you're still reading, the point here is supposed to be that on ARM
there are systems with and without a hardware FPU, and then bazillion
different ABIs which might or might not have to do with the FPU and its
calling conventions. On any sane system this would be communicated runtime
via hwcaps but this is ARM so what did you expect? Apparently there is
a way to get that during runtime by parsing the ELF headers of
/proc/self/exe but I'll leave that exercise to somebody else. So...
we only enable the FPU capability tests which determine the arm
architecture level when we're being compiled to -mfloat-abi=hard.
- If this all sounds crazy and convoluted, I agree. Its also entirely
possible I've misunderstood some/all of this, uh, subtlety, so dont
take my word for it. What do I know, I only work here.
- GCC apparently also got this wrong initially, AIUI this
only works reliably on gcc < 4.5 which dont support hw floating point
at all, and gcc >= 4.6 where __ARM_PCS_VFP is reliably defined when
appropriate.
- If you're STILL reading, this glorious one-liner is supposed to
replace the arch-dependent patch application of the kind of ARM
detection logic added in commit 2d67ca74c9
- Loosely based on similar patch in Fedora, but use hwcap instead
of parsing /proc/cpuinfo. Untested but hey, its only hardware
detection. What could possibly go wrong?
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>
- We'll need this to access any HWCAP_* bits for platforms that need it,
regardless of whether getauxval() is present or not. On glibc
systems this is likely to be equivalent, on others dunno (Solaris
appears to have sys/auxv.h header as well)
- A long time ago in a far away commit, "somebody" had this less than
brilliant idea that calling gethostbyname() loads all the required
name service libraries (commit 39b75d24cf).
This is of course only true if hosts db happens to use the same
database as passwd and group... which often is the case, but by
no means guaranteed or always the case.
- Add an explicit initializer for rpmug to force loading the name service
libraries early in initialization so we dont need to worry about going
chroot later on. Of course, the "host" name service configuration might
not actually make sense for the chroot, but this commit doesn't make
that any worse than it already was.
Without this change rpm incorrectly detects ppc64le systems as ppc64
(or ppc64p7). Compile time check the Endianness of the build system
to elide these checks on little endian.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
glibc >= 2.16 provides getauxval(): a reliable way to retrieve a value
from the auxiliary vector. It doesn't rely on /proc filesystem.
Let's switch to it and get rid of /proc dependency.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Perhaps this had some kind of meaning for the ancient implementors,
but that meaning has gotten long since lost in the sands of time
and most likely no longer exists at all...
- While adding the outer locks before converting all of internals
is easier here, it makes it also easier to forget places since
its not actually forced :-/ oh well...
- Should've been in commit 2870caa14c
- Similar to the context object in rpmlog, hide the global context
behind a function call to force controlled context acquisition.
We're going in the opposite direction here (because its simpler in
this case): there's nothing but the lock in the context now.
- Acquire and release the context on entry to public API
entry- and exit points, this should be enough to guarantee basic
safety (as in "does not crash and burn") wrt threads. Assuming
there are no hidden writers behind the getter APIs...
- For thread *sanity* all the umphteen globals need to go into the
context which could be per-thread initialized but that's a longer
story...
- Almost nothing works if crypto fails to initialize for whatever reason,
check and propagate rpmInitCrypto() failure from rpmReadConfigFiles().
- Logging the error left for individual crypto backends to let them
identify themselves: beecrypt requires no initialization whatsoever
so it cannot fail at all, but NSS can fail in a number of entertaining
ways due to missing dlopen()'ed bits and pieces, this should help
avoiding wild-goose chases in such cases (RhBug:909627, RhBug:909618...)
- There of course already is a drop-in directory for macro config bits
in $(sysconfdir)/rpm/ but as /etc is supposed to be per-host admin
territory, having another place for system package provided rpm config
doesn't seem unreasonable.
- Whether this early in the path is the best possible or even reasonable
position for this remains to be seen... but this way it could be used
for "factory default" config bits by rpm itself as well, while still
permitting vendor/host/user override.
- 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
- Presumably the rpmrc internals still need the magic table tennis
but nobody else should want to mess with this, reconfiguration
for another (build) arch is done through rpmReadConfigFiles().
- Eliminate pointless switch-case when we only care about one
possibility here. Also eliminate a dead-increment which becomes
more obvious now with the surroundings unobfuscated.
- An error here from rpmdsRpmlib() would be very much a "can't happen"
situtation, and there's no point handling it in any special way,
the loop will silently fall through anyway.
- For rpm itself forging global umask on init is kinda convenient, but can
be troublesome for API users. This is especially bad in python bindings
where just importing the rpm module silently changes process umask with
no good reason.
- Instead of global setting on init, only change the umask to 022 default
for the duration of rpmtsRun() where it's necessary for consistent
transaction results on implicitly created directories and files created
by scriptlets. This way we dont affect callers and provide better
"protection" for ourselves too - we don't know if API users change
umask again behind our back if we just set it on initialization.
- To make matters more fun, Lua scripts can change our umask. Save
and restore umask when running Lua scriptlets.
Michal Toman