Check for HAVE_STRONG_GETAUXVAL or HAVE_WEAK_GETAUXVAL before using getauxval to avoid a build failure on uclibc
Signed-off-by: Fabrice Fontaine fontaine.fabrice@gmail.com
Check for HAVE_STRONG_GETAUXVAL or HAVE_WEAK_GETAUXVAL before using getauxval to avoid a build failure on uclibc
Signed-off-by: Fabrice Fontaine fontaine.fabrice@gmail.com
Check for HAVE_STRONG_GETAUXVAL or HAVE_WEAK_GETAUXVAL before using
getauxval to avoid a build failure on uclibc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Concept ACK
Concept ACK
What a nice first-time contribution @ffontaine! Warm welcome as a contributor and hope to see more contributions in the future!
Won't this fail without HAVE_STRONG_GETAUXVAL, since randomenv doesn't define the weak variant?
The code change looks correct to me in any case.
But I'm surprised, uClibc doesn't have getauxval at all? It's a slight bit worrying to me because, besides random seeding, it's used for important kernel→userspace communication such as detecting what instruction sets are supported on ARM (and RISC-V and … probably many other architectures).
There is no getauxval on uclibc-ng: https://github.com/wbx-github/uclibc-ng/search?q=getauxval. If this is a security issue for you, I can disable bitcoin with uclibc-ng toolchains in buildroot.
I don't think it's a security issue. There are many random sources used on Linux, one less will not significantly make things worse I would expect.
Code review ACK 330cb33985d0ce97c20f4a0f0bbda0fbffe098d4
I think this change has no effect.
The HAVE_STRONG_GETAUXVAL as well as HAVE_WEAK_GETAUXVAL symbols are not defined. They have been introduced via the crc32c subtree and are only used as CRC32 CPPFAGS (see Makefile.crc32c.include).
removing from "needs backport" for now due to previous comment