diff options
author | Ross Burton <ross.burton@intel.com> | 2017-11-01 13:52:19 +0000 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2017-11-08 22:23:43 +0000 |
commit | 60aa20b8b691e5a72a6a11bf795b86c6359db886 (patch) | |
tree | 95cf195d174c2afe21b16e3f2464bccfcea86793 /meta/recipes-support/db/db | |
parent | 090eeccce74554bd4282b6a0407963037bc761a9 (diff) | |
download | openembedded-core-60aa20b8b691e5a72a6a11bf795b86c6359db886.tar.gz |
db: change types to avoid headers changing between architectures
Triggered by looking at why Python doesn't find db.h (because it greps db.h for
a regex, and db.h is actually a oe_multilib_header wrapper) I realised that the
only reason we have to oe_multilib_header db.h is because one typedef is
different between 32-bit and 64-bit architectures.
However, the typedef is for a 64-bit integer so instead of using long (64-bit)
or long long (32-bit), just use int64_t. Some of the overly complicated
configure tests need to be deleted after this change but that is safe as we're
building in a controlled environment and can assume int64_t exists.
With this done the header doesn't change between architectures, and it doesn't
need to be wrapped by oe_multilib_header.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Diffstat (limited to 'meta/recipes-support/db/db')
-rw-r--r-- | meta/recipes-support/db/db/sequence-type.patch | 59 |
1 files changed, 59 insertions, 0 deletions
diff --git a/meta/recipes-support/db/db/sequence-type.patch b/meta/recipes-support/db/db/sequence-type.patch new file mode 100644 index 0000000000..a6fe3d62a0 --- /dev/null +++ b/meta/recipes-support/db/db/sequence-type.patch @@ -0,0 +1,59 @@ +configure wants to use host-specific types to get a 64-bit integer in db.h +instead of using an alias such as int64_t. This means that the header differs +in multilib environments for no good reason, so replace the type with the alias +in stdint.h. + +This then breaks the overly complicated type check but as we know that int64_t +exists and works, we can just delete that. + +Upstream-Status: Pending +Signed-off-by: Ross Burton <ross.burton@intel.com> + +--- a/dist/aclocal/sequence.m4~ 2013-09-09 16:35:02.000000000 +0100 ++++ b/dist/aclocal/sequence.m4 2017-11-01 13:21:45.472295971 +0000 +@@ -24 +24 @@ +- db_cv_seq_type="long" ++ db_cv_seq_type="int64_t" +@@ -31 +31 @@ +- db_cv_seq_type="long long" ++ db_cv_seq_type="int64_t" +@@ -41,38 +41 @@ +- # Test to see if we can declare variables of the appropriate size +- # and format them. If we're cross-compiling, all we get is a link +- # test, which won't test for the appropriate printf format strings. +- if test "$db_cv_build_sequence" = "yes"; then +- AC_TRY_RUN([ +- main() { +- $db_cv_seq_type l; +- unsigned $db_cv_seq_type u; +- char buf@<:@100@:>@; +- +- buf@<:@0@:>@ = 'a'; +- l = 9223372036854775807LL; +- (void)snprintf(buf, sizeof(buf), $db_cv_seq_fmt, l); +- if (strcmp(buf, "9223372036854775807")) +- return (1); +- u = 18446744073709551615ULL; +- (void)snprintf(buf, sizeof(buf), $db_cv_seq_ufmt, u); +- if (strcmp(buf, "18446744073709551615")) +- return (1); +- return (0); +- }],, [db_cv_build_sequence="no"], +- AC_TRY_LINK(,[ +- $db_cv_seq_type l; +- unsigned $db_cv_seq_type u; +- char buf@<:@100@:>@; +- +- buf@<:@0@:>@ = 'a'; +- l = 9223372036854775807LL; +- (void)snprintf(buf, sizeof(buf), $db_cv_seq_fmt, l); +- if (strcmp(buf, "9223372036854775807")) +- return (1); +- u = 18446744073709551615ULL; +- (void)snprintf(buf, sizeof(buf), $db_cv_seq_ufmt, u); +- if (strcmp(buf, "18446744073709551615")) +- return (1); +- return (0); +- ],, [db_cv_build_sequence="no"])) +- fi ++ db_cv_build_sequence="yes" |