arm-linux-androideabi-readelf

本文详细介绍了如何使用arm-linux-androideabi-readelf命令来读取ELF文件的各种信息,包括文件头部、程序头部、节头部等,并提供了丰富的选项来定制读取需求。


使用arm-linux-androideabi-readelf读取信息:

arm-linux-androideabi-readelf

Usage: readelf <option(s)> elf-file(s)
 Display information about the contents of ELF format files
 Options are:
  -a --all               Equivalent to: -h -l -S -s -r -d -V -A -I
  -h --file-header       Display the ELF file header
  -l --program-headers   Display the program headers
     --segments          An alias for --program-headers
  -S --section-headers   Display the sections' header
     --sections          An alias for --section-headers
  -g --section-groups    Display the section groups
  -t --section-details   Display the section details
  -e --headers           Equivalent to: -h -l -S
  -s --syms              Display the symbol table
     --symbols           An alias for --syms
  --dyn-syms             Display the dynamic symbol table
  -n --notes             Display the core notes (if present)
  -r --relocs            Display the relocations (if present)
  -u --unwind            Display the unwind info (if present)
  -d --dynamic           Display the dynamic section (if present)
  -V --version-info      Display the version sections (if present)
  -A --arch-specific     Display architecture specific information (if any)
  -c --archive-index     Display the symbol/file index in an archive
  -D --use-dynamic       Use the dynamic section info when displaying symbols
  -x --hex-dump=<number|name>
                         Dump the contents of section <number|name> as bytes
  -p --string-dump=<number|name>
                         Dump the contents of section <number|name> as strings
  -R --relocated-dump=<number|name>
                         Dump the contents of section <number|name> as relocated bytes
  -w[lLiaprmfFsoRt] or
  --debug-dump[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,
               =frames-interp,=str,=loc,=Ranges,=pubtypes,
               =gdb_index,=trace_info,=trace_abbrev,=trace_aranges,
               =addr,=cu_index]
                         Display the contents of DWARF2 debug sections
  --dwarf-depth=N        Do not display DIEs at depth N or greater
  --dwarf-start=N        Display DIEs starting with N, at the same depth
                         or deeper
  -I --histogram         Display histogram of bucket list lengths
  -W --wide              Allow output width to exceed 80 characters
  @<file>                Read options from <file>
  -H --help              Display this information
  -v --version           Display the version number of readelf



关注我的技术公众号,查看更多优质技术文章推送

微信扫一扫下方二维码即可关注:

关注我的技术公众号,查看更多优质技术文章推送


<think>好的,我现在要解决用户的问题,关于Android NDK编译时出现的两个问题:一个是非系统库链接标志的警告,另一个是文件格式不被识别的错误。首先,我需要理解这两个问题的具体原因。 用户提到了两个错误:一个是使用非系统库的链接标志导致的警告,另一个是aarch64-linux-android-strip无法识别文件格式的错误。根据之前的对话历史,用户之前的问题是关于如何将两个.so文件合并成一个,现在可能是在尝试过程中遇到了新的问题。 首先,关于“non-system libraries in linker flags”的警告。这可能是因为用户在Android.mk或CMakeLists.txt中显式地链接了某些库,比如-lc++_shared,而NDK希望开发者通过正确的模块依赖来引用这些库,而不是直接使用链接标志。NDK推荐使用静态或共享库模块的方式,而不是直接通过LDLIBS添加。例如,对于c++_shared库,正确的方法应该是使用LOCAL_SHARED_LIBRARIES或者STL配置,而不是直接链接。 然后是“aarch64-linux-android-strip file format not recognized”错误。这个错误通常发生在构建系统尝试对某个文件执行strip操作,但该文件的格式不被strip工具识别。可能的原因是用户错误地将静态库(.a)或其他非共享库文件作为共享库处理,或者预构建库的架构与目标架构不匹配。例如,如果预构建库是为arm64-v8a编译的,但构建时目标架构是armeabi-v7a,就会导致strip工具无法处理。 接下来,我需要参考用户之前的问题。用户之前的问题是合并两个.so文件,解决方案涉及将预构建库转换为静态库并链接到主模块中。这可能导致了现在的问题,因为处理静态库和共享库的方式不同。例如,如果在Android.mk中将预构建的.so文件声明为静态库,但没有正确配置模块类型和后缀,可能会导致strip工具处理错误。 另外,用户提到的-lc++_shared警告,可能是因为他们直接使用了该链接标志,而正确的方法应该是通过STL配置。例如,在Application.mk中指定APP_STL := c++_shared,而不是在LDLIBS中添加。这可能导致NDK认为这是一个非系统库,从而产生警告。 现在需要综合这些信息,给出解决方案。首先解决链接警告,需要检查LOCAL_LDLIBS中是否包含-lc++_shared,并替换为正确的STL配置。其次,处理strip错误,需要检查预构建库的架构是否正确,以及是否错误地处理了文件类型。 可能的步骤包括: 1. 检查并更新STL配置,避免直接链接-lc++_shared。 2. 验证预构建库的架构是否与目标ABI匹配。 3. 确保预构建库的模块声明正确,特别是当使用静态库时,后缀和模块类是否正确。 4. 检查是否有其他非标准库被直接链接,导致警告。 5. 对于strip错误,可能需要检查生成的文件是否有效,或者是否在构建过程中错误地处理了某些文件。 此外,还需要考虑用户可能没有正确设置NDK版本或工具链,导致工具无法识别文件格式。建议用户检查NDK版本,并确保使用正确的工具链。 最后,生成相关问题,帮助用户进一步排查可能的问题,比如如何验证ABI兼容性,如何配置STL,如何处理符号冲突等。</think>### 一、问题根源分析 您遇到的编译警告和错误由以下核心因素导致: 1. **非系统库链接警告**:直接使用`-lc++_shared`而非通过NDK标准模块机制引用C++运行时库[^1] 2. **strip工具报错**:构建系统试图对非目标格式文件执行strip操作,通常由以下原因引发: - 预构建库架构与编译目标ABI不匹配(如x86库用于arm64编译) - 错误声明静态库为共享库(如将`.a`文件声明为`PREBUILT_SHARED_LIBRARY`) --- ### 二、分步解决方案 #### 步骤1:修复`-lc++_shared`警告 **正确配置STL运行时库**(以Android.mk为例): ```makefile # Application.mk APP_STL := c++_shared # 自动处理库依赖关系 # Android.mk LOCAL_LDFLAGS += -static-libstdc++ # 可选:静态链接C++标准库 ``` **移除直接链接标志**: ```diff - LOCAL_LDLIBS := -lc++_shared + # 通过APP_STL自动管理 ``` #### 步骤2:解决strip报错 **验证预构建库ABI兼容性**: ```bash # 查看预构建库架构信息 file libOPSCMCC.so # 输出应为当前编译目标架构,例如: # libOPSCMCC.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=..., stripped ``` **正确声明预构建库类型**: ```makefile # 若使用静态库整合(推荐方案) include $(CLEAR_VARS) LOCAL_MODULE := OPSCMCC LOCAL_SRC_FILES := prebuilt/libOPSCMCC.a # 必须是静态库文件 LOCAL_MODULE_CLASS := STATIC_LIBRARIES include $(PREBUILT_STATIC_LIBRARY) # 若必须使用共享库 include $(CLEAR_VARS) LOCAL_MODULE := OPSCMCC LOCAL_SRC_FILES := prebuilt/libOPSCMCC.so LOCAL_MODULE_CLASS := SHARED_LIBRARIES LOCAL_MODULE_TAGS := optional include $(PREBUILT_SHARED_LIBRARY) ``` #### 步骤3:配置多ABI支持 在`Application.mk`中明确指定目标架构: ```makefile APP_ABI := arm64-v8a armeabi-v7a # 按需选择 APP_PLATFORM := android-21 # 与原库编译平台一致 ``` --- ### 三、高级调试技巧 #### 1. 强制ABI一致性验证 ```bash # 检查NDK工具链与库的匹配性 $NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-readelf -h libOPSCMCC.so # 输出关键字段应包含: Machine: AArch64 OS/ABI: UNIX - System V ``` #### 2. 诊断strip错误根源 ```bash # 查看构建中间文件格式 find obj/local/ -name "*.so" -exec file {} \; # 错误示例(架构不匹配): libOPSCMCC.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped # 正确示例(arm64-v8a): libXinShengApp01.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped ``` #### 3. 动态加载验证(可选) 在Java层加载库时增加ABI检查: ```java static { try { System.loadLibrary("XinShengApp01"); } catch (UnsatisfiedLinkError e) { Log.e("ABI_CHECK", "Current ABI: " + Build.SUPPORTED_ABIS[0]); throw e; } } ``` --- ### 四、配置优化建议 #### 1. 使用现代NDK特性(推荐CMake) `CMakeLists.txt`示例: ```cmake cmake_minimum_required(VERSION 3.18.1) add_library(XinShengApp01 SHARED SimCard.cpp) # 正确链接预构建库 add_library(OPSCMCC STATIC IMPORTED) set_target_properties(OPSCMCC PROPERTIES IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/prebuilts/${ANDROID_ABI}/libOPSCMCC.a) target_link_libraries(XinShengApp01 OPSCMCC) # 配置C++标准库 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++") ``` #### 2. 控制符号暴露 ```makefile # Android.mk LOCAL_CPPFLAGS += -fvisibility=hidden LOCAL_CFLAGS += -fvisibility=hidden ``` --- ### 五、错误场景解决方案 #### 场景1:持续出现strip错误 **步骤**: 1. 清理构建缓存: ```bash ndk-build clean rm -rf obj/ libs/ ``` 2. 强制指定工具链版本: ```makefile NDK_TOOLCHAIN_VERSION := clang NDK_TOOLCHAIN := aarch64-linux-android-4.9 # 与原库编译工具链一致 ``` #### 场景2:C++符号未找到 ```makefile # 确保C++运行时正确初始化 LOCAL_CPP_FEATURES := rtti exceptions LOCAL_LDFLAGS += -Wl,--exclude-libs,libOPSCMCC.a # 隐藏静态库符号 ``` --- ### 六、构建验证流程 ```bash # 完整验证步骤 ndk-build clean ndk-build V=1 APP_ABI=arm64-v8a 2>&1 | tee build.log # 关键检查点: grep -E 'warning|error' build.log # 确认无关键错误 grep 'Install:' build.log # 检查输出路径 aarch64-linux-android-readelf -d libs/arm64-v8a/libXinShengApp01.so # 验证依赖项 ``` --- ### 七、替代方案对比 | 方法 | 优点 | 缺点 | 推荐指数 | |----------------------|--------------------------|--------------------------|--------| | 静态库整合 | 符号完全控制,无运行时依赖 | 需处理符号冲突 | ★★★★★ | | NDK-Build标准预构建 | 符合NDK规范 | 需要保持多个.so文件 | ★★★☆☆ | | CMake ExternalNativeBuild | 现代构建系统支持 | 需要重构配置 | ★★★★☆ | --- ### 相关问题 1. 如何在NDK中正确管理多个ABI版本的预构建库? 2. NDK编译时如何避免C++标准库符号冲突? 3. 使用CMake时如何配置预构建库的架构过滤?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hailushijie

您的鼓励是我创作最大的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值