Android NDK 中的 ICU 库

我正在尝试为依赖于 ICU 库（libicuuc.so 和 libicui18n.so）的 C 库创建 JNI 包装器。

我尝试在 NDK（标准版本和 CrystaX 版本，在 Mac OS X 机器上）中构建 ICU4C，并不断遇到如下链接问题：

/Users/kyip/KyVmShared/KyAndroid/myproject/obj/local/armeabi/objs/icuuc/udata.o: In function `openCommonData':
/Users/kyip/KyVmShared/KyAndroid/myproject/jni/icu4c/common/udata.c:836: undefined reference to `icudt42_dat'
/Users/kyip/KyVmShared/KyAndroid/myproject/obj/local/armeabi/objs/icuuc/ustr_wcs.o: In function `_strFromWCS':
/Users/kyip/KyVmShared/KyAndroid/myproject/jni/icu4c/common/ustr_wcs.c:365: undefined reference to `wcstombs'
/Users/kyip/KyVmShared/KyAndroid/myproject/jni/icu4c/common/ustr_wcs.c:415: undefined reference to `wcstombs'
/Users/kyip/KyVmShared/KyAndroid/myproject/jni/icu4c/common/ustr_wcs.c:314: undefined reference to `wcstombs'
/Users/kyip/KyVmShared/KyAndroid/myproject/obj/local/armeabi/objs/icuuc/ustr_wcs.o: In function `_strToWCS':
/Users/kyip/KyVmShared/KyAndroid/myproject/jni/icu4c/common/ustr_wcs.c:164: undefined reference to `mbstowcs'
collect2: ld returned 1 exit status

我也尝试了给出的建议android ndk 中的 unicode 支持但没有运气。我被困在：

arm-eabi-g++ -I/ky/crystax/android-ndk-r4-crystax/build/platforms/android-8/arch-arm/usr/include/ -O3 -fno-short-wchar -DU_USING_ICU_NAMESPACE=0 -DU_GNUC_UTF16_STRING=0 -fno-short-enums -nostdlib -fPIC -DU_COMMON_IMPLEMENTATION  -D_REENTRANT -I../common -I../../icu/source/common -I../../icu/source/i18n   "-DDEFAULT_ICU_PLUGINS=\"/usr/local/lib/icu\" "  -DU_COMMON_IMPLEMENTATION -DHAVE_CONFIG_H  -I/ky/crystax/android-ndk-r4-crystax/build/platforms/android-8/arch-arm/usr/include/ -O3 -fno-short-wchar -DU_USING_ICU_NAMESPACE=0 -DU_GNUC_UTF16_STRING=0 -fno-short-enums -nostdlib -fPIC -DU_COMMON_IMPLEMENTATION  -std=c++0x  -fvisibility=hidden -c   -o errorcode.ao ../../icu/source/common/errorcode.cpp
In file included from ../../icu/source/common/unicode/ptypes.h:23,
                 from ../../icu/source/common/unicode/umachine.h:52,
                 from ../../icu/source/common/unicode/utypes.h:36,
                 from ../../icu/source/common/errorcode.cpp:17:
/ky/crystax/android-ndk-r4-crystax/build/platforms/android-8/arch-arm/usr/include/sys/types.h:122: error: 'uint64_t' does not name a type
make[1]: *** [errorcode.ao] Error 1
make: *** [all-recursive] Error 2

任何帮助，将不胜感激。

看来这个问题涉及到两个文件。 icu/source/common/unicode/ptypes.h 调用 sys/types.h 包括

#if ! U_HAVE_UINT64_T
    typedef unsigned long long uint64_t;
/* else we may not have a 64-bit type */
#endif

通过包含 Android 中的 sys/types.h，我们涉及（第 122/124 行附近）

#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

看来uint64_t在赋值给u_int64_t时还没有声明。事实上，sys/types.h 包含 stdint.h，它具有以下内容：

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

typedef __int8_t      int8_t;
typedef __uint8_t     uint8_t;
typedef __int16_t     int16_t;
typedef __uint16_t    uint16_t;
typedef __int32_t     int32_t;
typedef __uint32_t    uint32_t;
#if defined(__STDC_INT64__)
typedef __int64_t     int64_t;
typedef __uint64_t    uint64_t;
#endif

Likely 严格_ANSI没有定义。看起来这是 sys/types.h 中 Android 代码中的一个错误。如果STDC_INT64没有定义，它不会定义uint64_t，所以它不能定义u_int64_t。也许真正的解决方案是修改 sys/types.h 以便它具有

#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;
$if defined(__STDC_INT64__)
typedef uint64_t       u_int64_t;
#endif
#endif

如果修复此问题，下一个错误将出现在 cstring.h:109 中

icu/source/common/cstring.h:109: error: 'int64_t' has not been declared

如果你改为#defineSTDC_INT64在 common/unicode/ptypes.h 中，它将走得更远，但将结束于

icu/source/common/ustrenum.cpp:118: error: must #include <typeinfo> before using typeid

更多信息请参见此处：http://groups.google.com/group/android-ndk/browse_thread/thread/2ec9dc289d815ba3?pli=1但没有真正的解决方案