haskell - GHC是否应链接同一库的不同版本？

Question

我正在尝试使用GHC 7.6.3编译程序，但出现错误

/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers':
(.text+0x300): multiple definition of `pPrPr_disableITimers'
/home/tom/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

(问题最终来自 readProcessWithExitCode的使用，但我认为这不是特别重要)

如果我使用 ghc运行 -v，那么我会在命令行参数中看到

'-L/home/tom/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0'

'-L/usr/lib/ghc/unix-2.6.0.1'

'-lHSunix-2.7.1.0'

'-lHSunix-2.6.0.1'

这是一个错误吗？ GHC是否真的应该尝试链接两个不同版本的 unix？

Answer 1

因此，您本身并未在此bug中给我足够的信息，但是我将尝试使用我的心理调试能力来回答您的问题。

您试图编译依赖于p和q包的GHC程序。您可能使用-package p和-package q指定了它们。您的软件包数据库可能看起来像这样(或可传递地看起来像这样):

id: p-0.1-8aa5d403c45ea59dcd2c39f123e27d57
depends: unix-2.6.0.1-9ce33138f4fcfb9c37f6e6c300bcc367

id: q-0.1-d5221a8c8a269b66ab9a07bdc23317dd
depends: unix-2.7.1.0-2f15426f5b53fe4c6490832f9b20d8d7

id: unix-2.6.0.1-9ce33138f4fcfb9c37f6e6c300bcc367
depends: (none)

id: unix-2.7.1.0-2f15426f5b53fe4c6490832f9b20d8d7
depends: (none)

当GHC查找软件包 p时，它将看到 p-0.1-8aa5d403c45ea59dcd2c39f123e27d57并决定使用它。然后，当它寻找包 q时，它将看到 q-0.1-d5221a8c8a269b66ab9a07bdc23317dd并决定使用它。然后，它进行一致性检查，以确保对于任何软件包id foo-0.1，都不会选择两个已安装的软件包ID。在我的示例中，这确实是正确的，因为所选择的 unix的两个版本具有不同的程序包ID( unix-2.6.0.1和 unix-2.7.1.0)，并且我灵敏的调试能力说，在扩展程序包数据库中，这也是事实。 (顺便说一句，如果您正在运行GHC 7.10，那么阴影检查将确保它没有选择两个不同的已安装软件包ID的任何软件包密钥。因此几乎可以肯定地保证是真的。)

因此，GHC接受kaboodle，我们尝试链接两个不同版本的 unix。糟糕!

那你该怎么办？这是您的选择。

使用Cabal。 Cabal将强制执行更严格的约束，即对于每个“PACKAGE NAME”，只有一个“PACKAGE VERSION”。因此，当您尝试cabal configure时，它将告诉您它无法解决依赖性，或者选择针对q而不是unix-2.6.0.1安装的unix-2.7.1.0的较早版本

查看并查看是否有针对较旧的q安装的unix版本，并明确要求它。默认情况下，如果一个软件包有多个可能的选择，GHC将选择最新版本。您可以告诉它使用早期版本。

重新安装针对p编译的较新版本的unix-2.7.1.0。然后，GHC会捡起它，并且没有不兼容的情况。请注意，它必须是较新的版本，因为今天的Cabal不允许您将针对p-0.1 AS WELL编译的unix-2.6.0.1副本作为针对p-0.1编译的unix-2.7.1.0副本。傻吧？我们正在尝试修复它。

删除.cabal和.ghc目录，然后cabal install最新版本的unix，然后进行其他操作。然后，一切都会(可能)针对新版本的unix进行编译，不会有问题。

这里是另外三个，不是那么有用的解决方案:

请注意，您实际上只得到此链接错误，因为unix具有C源，即使在不同版本的软件包中，这些源也被分配了相同的名称(Haskell标识符不是这种情况，它们带有适当的版本前缀)。如果unix是固定的，以便其所有C符号都带有版本前缀，则您将不会看到此问题，并且程序可以正常编译。好吧，除非您尝试同时使用两种不同版本的unix的类型(否则，您会被告知unix-2.6.0.1:BlahBlah与unix-2.7.1.0:BlahBlah不同。如果您很幸运。)目前尚无约定如何执行此操作，但是有一张关于它的GHC票:https://ghc.haskell.org/trac/ghc/ticket/9351

最近，有人提出GHC在实施阴影时应实施更强的一致性约束，即Cabal实施的约束。在那个世界中，GHC将无法找到p或q之一，并且将报告并非所有软件包都令人满意。会更好吗？这样做的计划是让Cabal管理软件包数据库的一致“ View ”，这样，当您单独使用ghc时，您将永远看不到实际上不应该看到的软件包。这就是这个GSoC项目:https://www.google-melange.com/gsoc/project/details/google/gsoc2015/vishal4556/5634387206995968

也许您可能会说:“忘掉所有这些花哨的 View 业务吧，实际上，GHC应该对尝试使用的软件包进行更好的一致性检查，以确保它与名称到版本映射的一致性。” (顺便说一句，简化的检查将是安装程序可执行程序当前所做的检查)。去年夏天，我试图说服邓肯相信GHC应该这样做，但是他坚信这是Cabal的工作，我们不应该在GHC中重复此代码。因此，到目前为止，GHC Bugtracker上没有任何票证表明我们应该这样做。