为什么我用 -LTO 构建的 C++ 二进制文件非常大？

Question

我正在 Mac 上编译一些二进制文件，但使用更新的编译器（从之前的 ~5MB 增加到 ~20MB），编译后的大小变得很大。我认为这与之前未激活的 LTO（链接时间优化）有关。我没有在 linux 上观察到这个文件膨胀。

在玩过strip 之后（实际上没有减小大小，尽管尝试了基于标志-S -x 并且也没有标志的Xcode，并且由带有标志-s 的自制binutils 配方提供的GNU libtools 条带，所有这些似乎达到同样的效果）我找到了这个工具：https://github.com/google/bloatyBloaty McBloated，当在我的二进制文件上运行时，它会产生这个输出：

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  53.9%  9.72Mi  53.8%  9.72Mi    __GNU_LTO,__wrapper_sects
  32.5%  5.86Mi  32.4%  5.86Mi    __GNU_DWARF_LTO,__debug_info
   6.2%  1.11Mi   6.2%  1.11Mi    __TEXT,__text
   2.2%   403Ki   2.2%   403Ki    __TEXT,__eh_frame
   1.6%   298Ki   1.6%   298Ki    __GNU_LTO,__wrapper_names
   1.0%   177Ki   1.0%   177Ki    Export Info
   0.7%   131Ki   0.7%   131Ki    Weak Binding Info
   0.4%  77.0Ki   0.4%  77.0Ki    __GNU_DWARF_LTO,__debug_str
   0.4%  75.8Ki   0.4%  75.8Ki    __DATA,__gcc_except_tab
   0.2%  44.6Ki   0.2%  44.6Ki    __GNU_LTO,__wrapper_index
   0.2%  39.4Ki   0.2%  39.4Ki    __DATA_CONST,__const
   0.2%  33.1Ki   0.2%  33.1Ki    __GNU_DWARF_LTO,__debug_abbrev
   0.1%  26.4Ki   0.1%  26.4Ki    __GNU_DWARF_LTO,__debug_line
   0.1%  21.7Ki   0.1%  23.6Ki    [20 Others]
   0.1%  19.0Ki   0.1%  19.0Ki    __TEXT,__text_cold
   0.1%  18.1Ki   0.1%  18.1Ki    __TEXT,__const
   0.0%  8.82Ki   0.0%  8.82Ki    __TEXT,__text_startup
   0.0%  8.60Ki   0.0%  8.60Ki    __TEXT,__cstring
   0.0%       0   0.0%  7.18Ki    __DATA,__pu_bss5
   0.0%       0   0.0%  6.88Ki    __DATA,__bss5
   0.0%  5.87Ki   0.0%  5.87Ki    __DATA,__la_symbol_ptr
 100.0%  18.1Mi 100.0%  18.1Mi    TOTAL

那么谁能告诉我这些巨大的*_LTO 部分的用途，以及我如何通过后处理或向我的构建链添加编译标志来摆脱它们。

OS 是 MacOS，我使用的是 g++ 10，这里有完整的跟踪： https://github.com/yanntm/testGithbuActions/runs/1778387086?check_suite_focus=true

我正在尝试尽可能多地编译静态以获得更好的可移植性。然而，二进制文件仍然动态链接到 /usr/lib/libSystem.B.dylib （我不能静态链接这个显然与 libtool）。

我不想要任何调试符号，因为这是面向最终用户的生产二进制文件。

Answer 1

你会找到答案in gcc's documentation：

链接时间优化是作为 GCC 前端实现的 在特殊部分发出的 GIMPLE 的字节码表示 .o 个文件。

[...]

由于 GIMPLE 字节码与最终的对象代码一起保存，因此对象 使用 LTO 支持生成的文件比常规目标文件大。

[...]

当前的实现只产生“胖”对象，有效地 编译时间加倍，文件大小最多增加 5 倍 原尺寸。

但是等等，还有更多。您仅使用 -flto 构建。如果您还使用了-ffat-lto-objects，那么，如 gcc 的信息页面中所述：

'-ffat-lto-objects'

胖 LTO 对象是包含中间体的对象文件 语言和目标代码。这使得它们可用于 LTO 链接和正常链接。此选项仅在以下情况下有效 使用 '-flto' 编译并在链接时被忽略。

尝试使用strip 将是徒劳的。 strip 只去除调试数据。这不是调试数据，而是基本上半编译的 C++ 代码，最终编译作为链接周期的一部分发生。如果您想“摆脱它们”，请不要使用 LTO。

编辑：某些 gcc/binutils 配置可能会将 LTO 部分留在目标二进制文件中。我研究了 Fedora 的默认 rpmbuild 配置，它默认使用 LTO 构建，但不会遭受相同的可执行文件膨胀。

事实证明，Fedora 的 rpmbuild 执行了一个 brp-strip-lto 脚本，归结为：

sh -c "$STRIP -p -R .gnu.lto_* -R .gnu.debuglto_* -N __gnu_lto_v1 \"\$@\"" ARG0

关键选项是两个-R 选项，不清楚__gnu_lto_v1 符号是什么，它被-N 删除。