Haskell 工具栈和可执行文件大小答案

【问题标题】：Haskell Tool Stack and executable sizeHaskell 工具栈和可执行文件大小
【发布时间】：2019-11-26 09:34:08
【问题描述】：

我使用 Stack tool 创建了一个 Haskell CLI。感谢 Travis，我刚刚成功设置了交叉编译，但我不明白为什么 linux (6MB)、osx (2MB) 和 windows (18MB!) 之间的可执行文件大小如此不同。怎么会？

发布：https://github.com/unfog-io/unfog-cli/releases/tag/v0.1.2

特拉维斯会议：https://github.com/unfog-io/unfog-cli/blob/master/.travis.yml

编辑

当我使用 tar.gz 压缩可执行文件时，我减少了差异，但仍然如此！我现在有 linux (1.35MB)、osx (0.61MB)、windows (3.93MB)（见release）

【问题讨论】：

对此我不太了解，但对此有一些疑问。给它看看。这可能会有所帮助stackoverflow.com/questions/12719207/…
感谢您的链接，我会检查一下，但它似乎解决了更多“为什么这么大”的问题。我的观点更多的是关于“为什么操作系统之间的大小如此不同”。

标签： haskell cross-platform travis-ci executable haskell-stack

【解决方案1】：

Linux 和 MacOS 构建之间的差异可能是由于称为“split sections”的东西。

在 Linux 上启用 -split-sections GHC 标志会将每个已编译的函数放入其自己的链接器部分（而不是将所有函数放入单个“.text”部分的历史方法）。这允许链接器以其他方式无法实现的粒度删除未使用的代码。

不幸的是，所有依赖项都需要使用此标志构建才能受益。您可以通过在项目的 stack.yaml 文件中添加以下行来强制 Stack 正确重建所有内容：

ghc-options:
    "$everything": -split-sections

这种为依赖项指定 GHC 选项的方法记录在 here。

如果您通过此更改重建 unfog，它实际上会从头开始重建“base”和“vector”以及其他所有内容，因此可能需要一段时间。但是，生成的二进制文件值得。不剥离，它的大小从大约 11Meg 下降到 4Meg，如果你剥离它，它只是：

-rwxr-xr-x 1 buhr buhr 1494696 Nov 27 19:40 unfog

比你发布的 MacOS 版本还要小。

现在，据我了解，原始 MacOS 版本只有 2Meg 的原因是 MacOS 链接器已经实现了类似于拆分部分的功能。我不确定是否也为 MacOS 构建启用 -split-sections 可能会带来额外的收益，或者 -split-sections 是否是 MacOS 下的自动默认设置。反正试一试也无妨。

对于 Windows，它如此庞大的主要原因是 MinGW GCC 工具链用于编译 Windows 二进制文件，因此存在 GNU ish 库（libc、libm、libpthread、libgmp 等）的完整兼容层，并且- 与 Linux 和 MacOS 版本不同 - 它们都静态链接到 Windows 二进制文件中。 Windows 的唯一动态链接是标准 Windows DLL。

请注意，-split-sections 可能适用于 Windows，也可能不适用于 Windows。错误跟踪器上有一些 cmets 使其不清楚。无论如何，可能值得一试，看看它是否有所作为。

一些额外的参考资料：

turning on -split-sections by default 的 GHC 错误跟踪器
对support -split-sections in Stack 的功能请求

【讨论】：