android - 即使在 CMake 中构建 Release 时，也会在最终 SO 文件中获取调试符号

Question

我正在使用 CMake(生成器是忍者)使用 NDK 工具链 (g++ 4.9) 构建共享库。下面是我使用 ninja 构建时在库中构建单个 CPP 文件的详细输出:

[34/164] /usr/local/bin/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DANDROID -DBOOST_ALL_NO_LIB -fexceptions -frtti -fpic -Wno-psabi --sysroot=/usr/local/bin/android-ndk/platforms/android-15/arch-arm -funwind-tables -finline-limit=64 -fsigned-char -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fdata-sections -ffunction-sections -Wa,--noexecstack -mthumb -fomit-frame-pointer -fno-strict-aliasing -O3 -DNDEBUG -isystem /usr/local/bin/android-ndk/platforms/android-15/arch-arm/usr/include -isystem /usr/local/bin/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /usr/local/bin/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem /usr/local/bin/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/backward -I/usr/local/bin/android-ndk/sources/android/cpufeatures -I/usr/local/bin/android-ndk/sources/android/native_app_glue -ICore/Artifacts/Android -IApplications/Survey/Source -ICore/UI/. -ICore/UI/Source -ICore/ThirdParty/PowerVR/sdk/Include -ICore/ThirdParty/PowerVR/tools/include -ICore/ThirdParty/PowerVR/tools/include/OGLES2 -ICore/ThirdParty/boost/include -ICore/ThirdParty/openssl/include -ICore/ThirdParty/sqlite/include -ICore/WebServices/Source -std=gnu++14 -MMD -MT Applications/Survey/CMakeFiles/Survey.dir/Source/View/RadioGroup.cpp.o -MF Applications/Survey/CMakeFiles/Survey.dir/Source/View/RadioGroup.cpp.o.d -o Applications/Survey/CMakeFiles/Survey.dir/Source/View/RadioGroup.cpp.o -c Applications/Survey/Source/View/RadioGroup.cpp

请注意，我在生成时指定了 -DCMAKE_BUILD_TYPE=Release。

命令行调用中不存在 -g 选项，但最终二进制文件为 19MB:

-rwxrwxr-x 1 bamboo bamboo 19173588 Jul 15 10:30 libzApp.so*

我对它运行了 size 以确定是什么让它变得如此巨大，但我得到了这个:

$ size libzApp.so
   text    data     bss     dec     hex filename
7097019  201268   53488 7351775  702ddf libzApp.so

那只占 7mb 的数据。所以我运行了这个:

$ objdump --debugging libzApp.so | head -25

libzApp.so:     file format elf32-little

Contents of the .debug_abbrev section:

  Number TAG (0x0)
   1      DW_TAG_compile_unit    [has children]
    DW_AT_producer     DW_FORM_strp
    DW_AT_language     DW_FORM_data1
    DW_AT_name         DW_FORM_strp
    DW_AT_comp_dir     DW_FORM_strp
    DW_AT_low_pc       DW_FORM_addr
    DW_AT_entry_pc     DW_FORM_addr
    DW_AT_ranges       DW_FORM_data4
    DW_AT_stmt_list    DW_FORM_data4
    DW_AT value: 0     DW_FORM value: 0
   2      DW_TAG_typedef    [no children]
    DW_AT_name         DW_FORM_strp
    DW_AT_decl_file    DW_FORM_data1
    DW_AT_decl_line    DW_FORM_data1
    DW_AT_type         DW_FORM_ref4
    DW_AT value: 0     DW_FORM value: 0
   3      DW_TAG_base_type    [no children]
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_encoding     DW_FORM_data1

我认为这几乎可以证实它具有调试符号。谁能帮我理解为什么 .so 这么大？假设这是因为调试符号，命令行调用会导致什么？

编辑

正如评论部分所建议的那样，在 SO 文件上运行 strip 肯定会将其大小降低到预期值(基本上是我们从 size 命令的结果中看到的).但是，当我明确告诉 GCC 不要构建调试符号时，为什么要将调试符号构建到共享对象中？我在这里遗漏了什么吗？

Answer 1

我可以建议你使用strip来删除调试信息，例如:

strip libzApp.so

这样做并没有那么糟糕，因为例如，Qt 的构建系统 qmake 总是在生成的 Makefile 的 install 目标中执行此操作。

默认情况下，编译器总是在二进制文件中添加重定位信息和符号表。它还添加了许多其他信息，这些信息可能会被删除(请参阅下面的答案链接)。

你也可以使用 -s 参数给编译器:

g++ -s ...

根据文档:

-s:

Remove all symbol table and relocation information from the executable.

此标志应与 strip 完全相同。这里还有some similiar answer on stackoverflow .