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?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With