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.

(From OE-Core rev: 6c9ffa50d00a55122ed861e1818186035fd89715)

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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"