Компиляция ICU для Android - uint64_t не называет тип - PullRequest
4 голосов
/ 12 февраля 2012

При попытке кросс-компиляции ICU с помощью android-ndk-r7 в Linux следующая ошибка возникает после настройки при запуске 'make'

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

Это вызвано #include в icu / source / common / unicode / ptypes.h: 25. Похоже, что это не проблема icu в Android-ndk-n7. В 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;
typedef uint64_t       u_int64_t;
#endif

Здесь используется код uint64_t, определенный в #include в верхней части файла sys / types.h. Здесь мы видим

#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

Если STRICT_ANSI или STDC_VERSION и, следовательно, STDC_INT64 никогда не будут определены, в том числе sys / types.h выдаст ошибку, так как uint64_t никогда не определяется. Любой код, который позже вызывает либо int64_t (происходит в коде icu), либо uint64_t, также выдаст ту же ошибку. Мое временное исправление для этого - определить STDC_INT64 в верхней части icu ptypes.h прямо перед #include . Это плохая идея?

Ответы [ 5 ]

12 голосов
/ 13 февраля 2012

Основная проблема заключается в том, что uint64_t не является определенным типом в версиях C до C99.Лучший способ определить это - сообщить gcc, какой стандарт вы хотели бы использовать.

Для c ++ это флаг -std=gnu++0x.Для C это означает -std=c99

Т.е. добавить строку типа

APP_CPPFLAGS= -std=gnu++0x

в файл Application.mk.

В качестве альтернативы, вы можете просто взломать ееваш #define;Я просто не стал бы распространять код с таким взломом, так как он хрупкий.

3 голосов
/ 20 марта 2012

-D__STDC_INT64__ позволяет определять uint64_t и int64_t в Android stdint.h.

Однако это не идеальное решение. Ошибка связана с Android, stdint и -std = c ++ 0x. См. В чем разница в GCC между -std = gnu ++ 0x и -std = c ++ 0x и какой из них следует использовать? для получения дополнительной информации. Если вы следите за ходом мысли, альтернативное (лучше?) Исправление состоит в том, чтобы изменить скрипт конфигурации icu так, чтобы он вызывал gnu ++ 0x вместо c ++ 0x. Наверное, это правильно.

*** 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.  */

***************
1 голос
/ 31 июля 2012

Я решил эту ситуацию, добавив в icudefs.mk в CPPFLGAS опцию -D__STDC_INT64 __

0 голосов
/ 06 июня 2013

Обновление до NDK 8e поддерживает больше вещей из C ++ 11

Также ваш Application.mk должен содержать некоторые флаги, посмотрите на мой файл

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
0 голосов
/ 13 февраля 2012

Можете ли вы установить -DU_HAVE_UINT64_T=0?

...