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

Question

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

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

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

编辑

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

Answer 1

Linux 和 MacOS 版本之间的差异可能是由于称为“split sections ”的原因造成的。

在 Linux 上启用 -split-sections GHcflags会将每个编译的函数放入其自己的链接器部分(而不是历史上将所有函数放入单个“.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 是否会带来额外的 yield ，或者 -split-sections 是否有效MacOS 下自动默认。不管怎样，尝试一下总没有坏处。

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

请注意，-split-sections 可能在 Windows 上工作，也可能不工作。错误跟踪器上的一些评论使其不清楚。不管怎样，也许值得尝试一下，看看是否会有所不同。

一些额外的引用:

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