android NDK中prebuild工具链和自定义工具链编译器之间的区别

时间:2017-05-09 21:53:25

标签: android c++ android-ndk cross-compiling icu

所以我试图弄清楚如何为Android构建ICU。最初我尝试用独立的工具链来制作它,经过一些战斗后我至少可以做到x86_64 arch(没有尝试过其他人)。但是,我不想拥有完全自定义的构建系统,因此我决定如何使用预构建工具链来制作它。我发现它表现得非常不同 - 这很奇怪。因此,当我尝试使用独立工具链配置ICU时,这是我的命令:

  

icu / source / configure --disable-shared --enable-static --disable-dyload   --disable-extras --disable-tests --disable-samples --prefix = / icu / build --host = x86_64-linux-android --with-cross-build = / toplay / icu / icu_linux CC = / custom_toolchain /斌/铛   CXX = / custom_toolchain / bin中/铛++   LD = / custom_toolchain /斌/ x86_64的-Linux的Android平台的LD   AR = / custom_toolchain /斌/ x86_64的-Linux的Android平台的AR   CFLAGS =" -fPIC -DANDROID -fdata-sections -ffunction-sections"   CXXFLAGS =" -fPIC -DANDROID -frtti -fno-exceptions -fdata-sections   -ffunction截面"

所以,拥有所有相同的命令,但只更改预编译工具链中的编译器和工具,如下所示:

  

icu / source / configure --disable-shared --enable-static --disable-dyload   --disable-extras --disable-tests --disable-samples --prefix = / icu / build --host = x86_64-linux-android --with-cross-build = / toplay / icu / icu_linux CC = / ndk -bundle /工具链/ x86_64-4.9 /预建/ Linux的x86_64的/ bin中/铛   CXX = / NDK束/工具链/ x86_64-4.9 /预建/ Linux的x86_64的/ bin中/铛++   LD = / NDK束/工具链/ x86_64-4.9 /预建/ Linux的x86_64的/ bin中/ x86_64的-Linux的机器人-LD   AR = / NDK束/工具链/ x86_64-4.9 /预建/ Linux的x86_64的//斌/ x86_64的-Linux的机器人-AR   CFLAGS =" -fPIC -DANDROID -fdata-sections -ffunction-sections"   CXXFLAGS =" -fPIC -DANDROID -frtti -fno-exceptions -fdata-sections   -ffunction截面"

我得到了非常不同的配置步骤结果。我放置 there: TLDR:主要差异:在prebuild工具链案例系统中无法理解它的交叉编译模式,它找到nl_langinfostrtod_l在Android中不可用)如果独立的工具链最初可以构建ICU,在预建案例中,构建过程最终会破坏。

所以我的问题是:预构建和独立情况下的编译器和工具有什么区别,我需要添加哪些标志/设置才能使它在预构建的情况下工作?

1 个答案:

答案 0 :(得分:2)

这是预期的行为。我已在our bugtracker上回答了此问题。

  

我们的Clang默认使用x86 Linux,而不是任何Android版本。设置目标标志是独立工具链所做的众多事情之一。

     

我不确定你要解决的问题是什么。无论你使用autoconf做什么,基本上都是一个拼凑的独立工具链。独立工具链完全存在,用于处理这种情况。

在此处回答您的具体问题:

  

预构建和独立情况下编译器和工具之间的区别是什么以及我需要添加哪些标志/设置才能使其在预构建案例中工作?

独立工具链是具有不同目录布局的预构建工具链(因此编译器可以推断出binutils,sysroot和STL的位置)和一些默认标志(如Clang的-target)。如果你要做到这一点,你可以重新发明这个轮子(可能是使用-gcc-toolchain和一堆--sysroot-isystem-L的东西而不是改变目录结构。

如果"为什么这项工作没有开箱即用?"是一个后续问题,请记住,在Android中,您有许多架构,甚至更多目标版本的操作系统,以及少数可供选择的STL。 Clang和GCC目前都不能以能够处理所有Android变体的方式进行设置(长期我希望能够改变这一点,但这种情况有很长一段时间the road )。