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.