Compiling ICU for Android - 'uint64_t' does not name a type

Question

While attempting to cross-compile ICU using android-ndk-r7 in Linux, the following error occurs after configuration when I run 'make'

__/android-ndk-r7/platforms/android-8/arch-arm/usr/include/sys/types.h:124: error: 'uint64_t' does not name a type

This is triggered by the #include <sys/types.h> in icu/source/common/unicode/ptypes.h:25. It appears to be a non-icu issue in android-ndk-n7. In sys/types.h we see

#ifdef __BSD_VISIBLE
typedef unsigned char   u_char;
typedef unsigned short  u_short;
typedef unsigned int    u_int;
typedef unsigned long   u_long;

typedef uint32_t       u_int32_t;
typedef uint16_t       u_int16_t;
typedef uint8_t        u_int8_t;
typedef uint64_t       u_int64_t;
#endif

The culprint here is uint64_t, which is defined in #include <stdint.h> at the top of the sys/types.h. Here we see

#if !defined __STRICT_ANSI__ || __STDC_VERSION__ >= 199901L
#  define __STDC_INT64__
#endif

...

#if defined(__STDC_INT64__)
typedef __int64_t     int64_t;
typedef __uint64_t    uint64_t;
#endif

If STRICT_ANSI or STDC_VERSION and therefore STDC_INT64 are never definied, including sys/types.h will throw an error since uint64_t is never defined. Any code that later calls either int64_t (happens in icu code) and uint64_t will also throw the same error. My temporary fix for this is to define STDC_INT64 at the top of icu's ptypes.h right before #include <sys/types.h>. Is this a bad idea?

Answer 1

The main issue is that uint64_t isn't a defined type in C versions prior to C99. The best way to have it defined is to tell gcc which standard you'd like to use.

For c++, that's passing the -std=gnu++0x flag. For C, that's passing -std=c99

I.e. add a line something like

APP_CPPFLAGS= -std=gnu++0x

to your Application.mk file.

Alternatively, you can just hack it via your #define; I just wouldn't distribute code with such a hack as it's fragile.

Answer 2

-D__STDC_INT64__ allows uint64_t and int64_t to be defined in Android's stdint.h.

However, this is not the ideal fix. The error has to do with Android, stdint and -std=c++0x. See What's the difference in GCC between -std=gnu++0x and -std=c++0x and which one should be used? for further information. If you follow the train of thought, an alternate (better??) fix is to modify the icu configuration script so that it calls for gnu++0x instead of c++0x. That's probably the right thing to do.

*** 7238,7244 ****
          OLD_CFLAGS="${CFLAGS}"
          OLD_CXXFLAGS="${CXXFLAGS}"
          CFLAGS="${CFLAGS} -std=gnu99 -D_GCC_"
!         CXXFLAGS="${CXXFLAGS} -std=c++0x"
          cat confdefs.h - <<_ACEOF >conftest.$ac_ext
  /* end confdefs.h.  */

--- 7241,7247 ----
          OLD_CFLAGS="${CFLAGS}"
          OLD_CXXFLAGS="${CXXFLAGS}"
          CFLAGS="${CFLAGS} -std=gnu99 -D_GCC_"
!         CXXFLAGS="${CXXFLAGS} -std=gnu++0x"
          cat confdefs.h - <<_ACEOF >conftest.$ac_ext
  /* end confdefs.h.  */

***************

Answer 3

I have resolved this situation by adding in to icudefs.mk into CPPFLGAS an option -D__STDC_INT64__

Answer 4

Can you set -DU_HAVE_UINT64_T=0 ?

Answer 5

Update to NDK 8e it supports more things from C++11

Also your Application.mk should contains some flags look at my file

APP_STL := gnustl_static
APP_CPPFLAGS := -frtti -DCC_ENABLE_CHIPMUNK_INTEGRATION=1 -DCOCOS2D_DEBUG=1 -std=c++11 -DDEBUG=1
APP_USE_CPP0X := true
NDK_TOOLCHAIN_VERSION=4.7