path: root/utils
diff options
authorGravatar Yann E. MORIN <yann.morin.1998@free.fr>2021-03-03 19:16:34 +0100
committerGravatar Yann E. MORIN <yann.morin.1998@free.fr>2021-03-04 22:53:08 +0100
commitc72be5dd2f5aef9162a0ec90465d9220b3546887 (patch)
tree907114cec5921c25a464b75993687503d6504970 /utils
parente5594f7239547672c08058b77f8098d2c080bebc (diff)
package/libopenssl does not support riscv32
riscv32 is (surprise!) a 32-bit architecture. But it has been Y2038-safe from its inception. As such, there are no legacy binaries that may use the 32-bit time syscalls, and thus they are not available on riscv32. Code that directly calls to the syscalls without using the C libraries wrappers thus need to handle this case by themselves. That's what upstream tried to do with: https://github.com/openssl/openssl/commit/5b5e2985f355c8e99c196d9ce5d02c15bebadfbc We initially carried that patch with 2bb26c1a1d24 (package/libopenssl: fix build on riscv32). However, as Arnd Bergmann puts it [0]: The patch looks wrong to me: __NR_io_pgetevents_time64 must be used whenever time_t is 64-bit wide on a 32-bit architecture, while __NR_io_getevents/__NR_io_pgetevents must be used when time_t is the same width as 'long'. Checking whether __NR_io_getevents is defined is wrong for all architectures other than riscv And Arnd agrees that patch should be reverted [1] [2] (there are further comments in that stream, that are worth reading). As such, we've reverted 2bb26c1a1d24 with 6cfb4ad7f76a. This means we have no working solution to enable openssl on riscv32 for now. So, rather than fail the build, or backport a dysfunctional patch, let's just forbid openssl on riscv32. Drop the default from the choice selection; it was anyway superfluous: the default of a choice, if left unspecified, is the first entry of the choice. Also, having a default means we'd have to also propagate the dependencies of the defaulted-to symbol, which is yet a little bit more maintenance. Since the chances we get a third implementation of openssl are pretty slim (very, very slim), reasoning about what is the default is still very easy. When propagating dependencies to tpm2-tss' users, we've tried to keep the architecture dependency toward the top when possible, and otherwise we've added it together with existing arch dependencies (MMU). While at it, drop a useless redundant comment in ibm-sw-tpm2: if we select FORCE_LIBOPENSSL, it is obvious that's because libressl is not supported... Besides none of the other users of FORCE_LIBOPENSSL have such a comment. Fixes: http://autobuild.buildroot.org/results/eb9/eb9a64d4ffae8569b5225083f282cf87ffa7c681/ ... http://autobuild.buildroot.org/results/07e/07e413b24ba8adc9558c80267ce16dda339bf032/ [0] https://github.com/openssl/openssl/commit/5b5e2985f355c8e99c196d9ce5d02c15bebadfbc#commitcomment-44782859 [1] https://github.com/openssl/openssl/commit/5b5e2985f355c8e99c196d9ce5d02c15bebadfbc#commitcomment-47826509 [2] https://github.com/openssl/openssl/commit/5b5e2985f355c8e99c196d9ce5d02c15bebadfbc#commitcomment-47830530 Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Matthew Weber <matthew.weber@rockwellcollins.com> Cc: Mark Corbin <mark@dibsco.co.uk>
Diffstat (limited to 'utils')
0 files changed, 0 insertions, 0 deletions