> This seems like an odd result considering the BeagleBone Black > processor is closer to a NEON.
Well, ./config script should add -march=armv7-a option and that is more than enough to make it NEON-capable. In fact linux-armv4 target covers *all* post-v4 32-bit processors, it's all about additional flags. For those who want to distribute single software package suitable for multiple processors it's even possible to produce "universal" binaries (see commentary in 10-main.cf)... > This particular BBB is running a Debian > 8.2 based image. > > I also believe CFLAGS should include hard-floats (i.e., > -mfloat-abi=hard). This is something that is left to compiler vendor (by configuring defaults) or for user/packager to decide. > Without it, entropy estimates for some of the RAND_ > functions could produce incorrect results. Well, can you backup this statement? Even if you could, it would be compiler/run-time problem. If processor is not FP-capable, then it's normally emulated in system library, but results are consistent with FP-capable processor. Or at least if they are not, then it's a bug, and it's a bug in system libraries, not OpenSSL. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4196 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
