什么决定了 OS X 上 GHC 的链接行为？答案

【问题标题】：What determines linking behaviour for GHC on OS X?什么决定了 OS X 上 GHC 的链接行为？
【发布时间】：2014-12-05 19:52:15
【问题描述】：

我在编译二进制文件时观察到两台机器之间的不同链接行为。

每个都有相同的 GHC (7.8.3)、相同的代码、相同的标志 (-Wall -O2)、相同的 libgmp（由 Homebrew 安装在每个上）：

machine-one$ otool -L my-binary
my-binary:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

machine-two$ otool -L my-binary
my-binary:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/local/lib/libgmp.10.dylib (compatibility version 13.0.0, current version 13.0.0)

我一辈子都想不通为什么libgmp 会在第二台机器上动态链接。

就我能够识别的差异而言：GHC 已通过第一台机器上的binary distribution for OS X 和第二台机器上的 Homebrew 安装。对于 C 编译器，我们有：

machine-one$ cc --version
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

machine-two$ cc --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

通常是什么决定了链接行为，以及如何强制执行一种或另一种链接方法？

编辑：我观察到zlib 在另一台机器上发生了同样的行为，所以这不是 GMP 特定的问题。

编辑：我已经从每台机器上提取了ghc --info，这里是machine one 和machine two。这也是两者之间的the diff。

编辑：我已经通过分发二进制文件在机器 2 上重新安装了 ghc，当我重新编译我的二进制文件时，libgmp 确实没有动态链接。所以这似乎与通过 Homebrew 安装 GHC 有关。

仍然对到底发生了什么很感兴趣。

【问题讨论】：

我认为这可能部分取决于 GHC 的编译方式。您使用的两个发行版的编译方式是否不同？
一个类似的问题：(link) 这可能会有所帮助。
@dfeuer GHC 的安装方式确实不同 - 通过二进制文件与通过 Homebrew - 但我找不到任何关于在这两种情况下会发生什么的信息。 @user5402 我知道在 OS X 上无法传递静态链接标志，因为无法静态链接 libSystem 和 libiconv。
您能否将命令“ghc --info”的输出添加到您的问题中？
@harmic 我已经更新了帖子。

标签： macos haskell ghc static-linking dynamic-linking

【解决方案1】：

关键的区别在于机器#2 在链接器路径中有/usr/local/lib，并且使用的是brew 的链接器(/usr/local/Library/ENV/4.3/ld)。 ghc 仍然使用外部链接器，即使它没有使用 C 后端进行代码生成，因此您可以将 Haskell 代码与用其他语言编写的代码结合起来（对于 Haskell 与第三方库的许多 FFI 绑定至关重要）。所以你真的应该问酿酒人为什么事情的联系方式不同。这实际上不是ghc 问题。

【讨论】：