Now that we have a backport from upstream with a proper fix for the
build on riscv32 *and* a proper implementationfor 64-bit time structs,
we can re-activate the build on riscv32.
This partially reverts commit c72be5dd2f.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Alistair Francis <alistair.francis@wdc.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Mark Corbin <mark@dibsco.co.uk>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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:
5b5e2985f3
We initially carried that patch with 2bb26c1a1d (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 2bb26c1a1d with 6cfb4ad7f7.
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] 5b5e2985f3 (commitcomment-44782859)
[1] 5b5e2985f3 (commitcomment-47826509)
[2] 5b5e2985f3 (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>
In commit 26e37cef16, we started using
__WORDSIZE to get the size of longs on the given architecture, in
order to support all CPU architectures.
Unfortunately, __WORDSIZE is not enabled in musl, so in
19bd089004, we switched to using
LONG_BIT instead of __WORDSIZE.
However, LONG_BIT is not readily available on glibc, you need
_XOPEN_SOURCE to be defined, which was done in
a34e7f88f6.
However, in a34e7f88f6, _XOPEN_SOURCE
was just defined, with no specific value. This caused the build to
break again on uClibc-ng and older glibcs, because clock_gettime() and
CLOCK_MONOTONIC were no longer defined. In both uClibc-ng and glibc,
CLOCK_MONOTONIC is only defined if __USE_POSIX199309 is defined. It
turns out that simply defining _XOPEN_SOURCE with no value does not
lead to __USE_POSIX199309 being defined in uClibc-ng and old glibcs,
while it is defined in newer glibcs.
The difference comes from the following snippet of code, which is
present in recent enough glibc's <feature.h> but not uClibc-ng's or
older glibc's <feature.h>:
/* If none of the ANSI/POSIX macros are defined, or if _DEFAULT_SOURCE
is defined, use POSIX.1-2008 (or another version depending on
_XOPEN_SOURCE). */
So the fact that we are defining _DEFAULT_SOURCE makes it assume that
we're using POSIX 2008.09, which obviously includes POSIX 1993.09.
Due to the lack of this code snippet, uClibc-ng <features.h> only
enables:
!defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE)
but not:
So we need an _XOPEN_SOURCE level of at least 500 for POSIX 1993.09
definitions to be available.
This is confirmed by the feature_test_macros man page, which states:
_XOPEN_SOURCE < 500
_POSIX_C_SOURCE is defined with the value 2.
500 <= _XOPEN_SOURCE < 600
_POSIX_C_SOURCE is defined with the value 199506L.
When this is fixed, another issue arises with older glibc toolchains
(such as Sourcery ARM), where fd_set is no longer defined. Inded, with
POSIX-1.2001 being enabled, we need to include <sys/select.h> to
access the fd_set definition and friends (see man fd_set for details).
This commit was tested with two glibc toolchains (recent and old), one
uClibc-ng toolchain and one musl toolchain.
Fixes:
http://autobuild.buildroot.net/results/e20f9474fc0217036faa6561df33fa983466ddfe/
(uClibc-ng)
http://autobuild.buildroot.net/results/b5d944389fc96ef2c5e0608fe4ac34149e5f9739/
(glibc)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to not have to define all architecture bitness variants in
src/LibSupport.h to conditionally define RADIX_BITS, a patch was created
to depend on LONG_BIT being defined via limits.h
For glibc, LONG_BIT is behind a _XOPEN_SOURCE define guard so patch the
makefile to define this macro as well as _DEFAULT_SOURCE.
Defining _XOPEN_SOURCE requires _DEFAULT_SOURCE to be explicitly defined
for builds to succeed as it is no longer impliclty defined when
_XOPEN_SOURCE is defined.
Fixes:
http://autobuild.buildroot.net/results/bc145dd23c80a0660300766d0c114a00ed2e52b6/http://autobuild.buildroot.net/results/1d84e70c30d4d0719274aa4f3edc01772beb24a3/
Fixes: 19bd089004 ("package/ibm-sw-tpm2: fix patch to address musl builds")
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Previously, __WORDSIZE was being used to define RADIX_BITS.
__WORDSIZE is not defined consistently via limits.h across all libc
variants, so use LONG_BIT instead.
Fixes:
http://autobuild.buildroot.net/results/b5cb347a98dc64f77982633c0fc48d14030aa5b6/
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
src/LibSupport.h has some logic to find the wordsize of the current
architecture, using an explicit list of CPU architectures. This makes
the build fail on a number of CPU architectures that are not
explicitly handled.
Let's instead use the __WORDSIZE definition of the C library, which is
guaranteed to be available for all CPU architectures.
Fixes:
http://autobuild.buildroot.net/results/a235345477ea2ec3b0dd4ffed4d7667d46caec48/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This project is an implementation of the TCG TPM 2.0 specification. It
is based on the TPM specification Parts 3 and 4 source code donated by
Microsoft, with additional files to complete the implementation.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
