abi

本文档介绍了 ndk-build 所使用的 Application.mk 编译文件。 我们建议先阅读 概念 页面，然后再阅读本页面。 概览 Application.mk 指定了 ndk-build 的项目范围设置。默认情况下，它位于应用项目目录中的 jni/Application.mk 下。 注意 ：其中许多参数也具有模块等效项。例如， APP_CFLAGS 对应于 LOCAL_CFLAGS 。无论何种情况下，特定于模块的选项都将优先于应用范围选项。对于标记，两者都使用，但特定于模块的标记将后出现在命令行中，因此它们可能会替换项目范围设置。 变量 APP_ABI 默认情况下，NDK 编译系统会为所有非弃用 ABI 生成代码。您可以使用 APP_ABI 设置为特定 ABI 生成代码。表 1 显示了不同指令集的 APP_ABI 设置。 表 1. 不同指令集的 APP_ABI 设置。 指令集 值 32 位 ARMv7 APP_ABI := armeabi-v7a 64 位 ARMv8 (AArch64） APP_ABI := arm64-v8a x86 APP_ABI := x86 x86-64 APP_ABI := x86_64 所有支持的 ABI（默认） APP_ABI := all 您也可以指定多个值，方法是将它们放在同一行上，中间用空格分隔。例如： APP_ABI :=

使用预编译库 NDK 支持使用预编译库（同时支持静态库和共享库）。此功能有以下两个主要用例： 向第三方 NDK 开发者分发您自己的库（而不分发您的源代码）。 使用您自己的库的预编译版本来提升编译速度。 本页将介绍如何使用预编译库。 声明预编译库 您必须将自己使用的每个预编译库声明为一个独立模块。为此，请执行以下步骤： 为模块提供名称。此名称不需要与预编译库本身的名称相同。 在模块的 Android.mk 文件中，将指向您提供的预编译库的路径分配到 LOCAL_SRC_FILES 。指定 LOCAL_PATH 变量的值的相对路径。 注意 ：请务必选择与您的目标 ABI 对应的预编译库版本。要详细了解如何确保库支持 ABI，请参阅 为预编译库选择 ABI 。 根据您使用的是共享库 ( .so ) 还是静态库 ( .a )，添加 PREBUILT_SHARED_LIBRARY 或 PREBUILT_STATIC_LIBRARY 。 下面这个小例子假设预编译库 libfoo.so 与描述它的 Android.mk 文件位于同一个目录中。 LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := foo-prebuilt LOCAL_SRC_FILES := libfoo.so include $(PREBUILT

We recently caught a report because of GCC 5.1, libstdc++ and Dual ABI . It seems Clang is not aware of the GCC inline namespace changes , so it generates code based on one set of namespaces or symbols, while GCC used another set of namespaces or symbols. At link time, there are problems due to missing symbols. If I am parsing the Dual ABI page correctly, it looks like a matter of pivoting on _GLIBCXX_USE_CXX11_ABI and abi::cxx11 with some additional hardships. More reading is available on Red Hat's blog at GCC5 and the C++11 ABI and The Case of GCC-5.1 and the Two C++ ABIs . Below is from a

The title says everything. I am talking about C/C++ specifically, because both consider this as "implementation issue". I think, defining a standard interface can ease building a module system on top of it, and many other good things. What could C/C++ "lose" if they defined a standard ABI? The freedom to implement things in the most natural way on each processor. I imagine that c in particular has conforming implementations on more different architectures than any other language. Abiding by a ABI optimized for the currently common, high-end, general-purpose CPUs would require unnatural

For my Android-app I'm using the ABI "x86" and "armeabi" right now. The armeabi is used for all ARM-devices, including armv7a and arm64-v8a. Now I would like to remove the "armeabi" and just continue with "x86" and "armeabi-v7a". I haven't found any hint in the docs, that ARMv8 is also compatible with ARMv7 - can anyone confirm that my app will still work on devices running arm64-v8a, if I don't offer an armeabi but now an armeabi-v7a-library? Many new Android devices (i.e. Nexus 5x) have AArch64 processors with arm64-v8a instruction set. Both - armeabi and armeabi-v7a - libraries run fine on

From a discussion somewhere else : C++ has no standard ABI But neither does C, right? On any given platform it pretty much does. It wouldn't be useful as the lingua franca for inter-language communication if it lacked one. What's your take on this? C defines no ABI. In fact, it bends over backwards to avoid defining an ABI. Those people, who like me, who have spent most of their programming lives programming in C on 16/32/64 bit architectures with 8 bit bytes, 2's complement arithmetic and flat address spaces, will usually be quite surprised on reading the convoluted language of the current C

As far as I've understood, it is not possible to link libraries that use different versions of GCC's Application Binary Interface (ABI). Are there ABI changes to every version of GCC? Is it possible to link a library built with 4.3.1 if I use, say, GCC 4.3.2? Is there a matrix of some sort that lists all the ways I can combine GCC versions? ablaeul The official ABI page points to an ABIcheck . This tool may do, what you want. Since gcc-3.4.0, the ABI is forward compatible. I.E. a library made using an older release can be linked with a newer one and it should work (the reverse doesn't).

I'm working on a certain C++ library (or more framework). I want to make it backward compatible with previous versions preserving not only API compatibility but also ABI (like the great job Qt does). I use lots of functionality of Boost and it seems for me that this makes backward compatibility just impossible, unless I force a user to have exactly the same (sometimes old) version of Boost. Is there any way (without rewriting 1/2 of Boost) to make some "prefix" around its namespace/rename it in order to prevent it from interfering with a user version of Boost? For example my libXYZ uses Boost