编译arm64-v8a的Android NDK应用时预编译库兼容性异常

一、ARM v7库链接arm64-v8a应用的编译错误 #

问题场景 #

构建arm64-v8a ABI的Android NDK应用时，错误引用厂商提供的arm-android-clang8.0版本libSNPE.so，触发链接错误：

ld: error: <some_path>/build/intermediates/ndkBuild/debug/obj/local/arm64-v8a/libSNPE.so is incompatible with aarch64linux
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

通过arm-linux-androideabi-readelf.exe验证，该库为ARM v7架构：

.\arm-linux-androideabi-readelf.exe -A <path/to/library/arm-android-clang8.0/libSNPE.so>

输出结果：

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM v7"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv4
  Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
  Tag_ABI_PCS_GOT_use: GOT-indirect
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_CPU_unaligned_access: v6
  Tag_FP_HP_extension: Allowed
  Tag_ABI_FP_16bit_format: IEEE 754
  Tag_Virtualization_use: TrustZone

原因分析 #

• arm64-v8a对应64位aarch64指令集，而arm-android-clang8.0版本库是32位ARM v7指令集，两者属于完全不同的架构，链接器不允许混合链接不同指令集的库，因此抛出兼容性错误。
• 构建命令已明确指定APP_ABI=arm64-v8a，但预编译库的Android.mk错误指向32位版本，导致架构不匹配。

解决办法 #

确保预编译库ABI与目标APP_ABI完全匹配，修改预编译库的Android.mk：

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := snpe
LOCAL_SRC_FILES := $(SNPE_SDK_PATH)/lib/aarch64-android-clang8.0/libSNPE.so
include $(PREBUILT_SHARED_LIBRARY)

二、使用aarch64版本库的运行时段错误 #

问题场景 #

替换为aarch64-android-clang8.0版本库后编译通过，但运行时出现段错误，崩溃日志如下：

2023-02-14 13:43:48.703 18630-18775 libc                    pid-18630                            A  Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7072109ac8 in tid 18775 (OVR::Main), pid 18630 (cm.oculusavatar)
2023-02-14 13:43:48.793 18833-18833 DEBUG                   pid-18833                            A  *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2023-02-14 13:43:48.793 18833-18833 DEBUG                   pid-18833                            A  Build fingerprint: 'oculus/hollywood/hollywood:10/QQ3A.200805.001/37314400808900000:user/release-keys'
2023-02-14 13:43:48.793 18833-18833 DEBUG                   pid-18833                            A  Revision: '0'
2023-02-14 13:43:48.793 18833-18833 DEBUG                   pid-18833                            A  ABI: 'arm64'
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A  Timestamp: 2023-02-14 13:43:48+0300
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A  pid: 18630, tid: 18775, name: OVR::Main  >>> com.example.example <<<
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A  uid: 10096
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A  signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7072109ac8
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A      x0  0000007060501470  x1  0000007060500798  x2  0000000000000001  x3  000000706d4ee960
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A      x4  0000007060501470  x5  0000007072b05e98  x6  fefeff115c149b0a  x7  7f7f7f7f7f7fff7f
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A      x8  0000007072109ac8  x9  0000000000000003  x10 0000000000004957  x11 0000000000004957
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A      x12 0000000000000001  x13 0000000000000000  x14 ffffffffffffffff  x15 0000000000000050
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A      x16 000000707212c478  x17 000000715b8c05a0  x18 0000000000000100  x19 0000007060500798
2023-02-14 13:43:48.794 18833-18833 DEBUG                   pid-18833                            A      x20 000000706d4ee960  x21 0000000000000001  x22 0000000000000002  x23 0000007060501470
2023-02-14 13:43:48.795 18833-18833 DEBUG                   pid-18833                            A      x24 0000000000000000  x25 0000007072109908  x26 0000007072109a18  x27 0000007060501838
2023-02-14 13:43:48.795 18833-18833 DEBUG                   pid-18833                            A      x28 0000007060503018  x29 0000007060500770
2023-02-14 13:43:48.795 18833-18833 DEBUG                   pid-18833                            A      sp  0000007060500770  lr  0000007072b0a3f8  pc  0000007072109ac8
2023-02-14 13:43:49.125 18833-18833 DEBUG                   pid-18833                            A  
                                                                                                    backtrace:
2023-02-14 13:43:49.125 18833-18833 DEBUG                   pid-18833                            A        #00 pc 0000000000001ac8  /data/app/com.example.example-DCjlQwt6O7adQRp_vv3W8g==/base.apk

原因分析 #

1. 编译器版本不匹配：预编译库用clang8.0编译，当前构建使用的NDK 24对应clang14，跨大版本编译器可能导致C++标准库实现、符号命名或ABI规则差异，引发运行时异常。
2. 依赖库缺失或不匹配：SNPE库可能依赖其他系统/第三方库，这些库在目标设备（Oculus Hollywood，Android 10）上的版本与库编译时依赖版本不一致，导致加载或调用失败。
3. 参数传递错误：SEGV_ACCERR表示访问无权限内存区域，大概率是调用SNPE API时传递非法参数（如空指针、内存越界、结构体大小不匹配），或JNI层参数转换错误。
4. ASAN兼容性问题：构建命令启用了USE_ASAN=1，部分预编译库未适配ASAN，导致运行时内存检测逻辑冲突。

解决办法 #

• 对齐编译器版本：将NDK版本降级到与预编译库匹配的版本（NDK 17/18对应clang8），消除跨版本编译器的ABI差异。
• 检查依赖库：使用readelf -d <path/to/aarch64/libSNPE.so>查看库的依赖项，确认所有依赖库已正确打包到APK且ABI为arm64-v8a。
• 排查调用参数：检查调用SNPE库的代码，特别是JNI层参数传递，确保所有指针、数据大小、结构体类型符合库要求；增加日志跟踪崩溃前的函数调用流程，定位具体触发崩溃的API。
• 禁用ASAN测试：暂时移除构建命令中的USE_ASAN=1，重新构建运行。若崩溃消失，说明ASAN与预编译库不兼容，后续可改用gdb等调试工具。
• 验证库初始化流程：确认SNPE库的初始化步骤正确，确保调用核心API前完成库的加载和配置初始化。

内容的提问来源于stack exchange，提问作者Alexey S. Larionov