我常常不喜欢两件事情，一起引起我很多烦恼（除了我的孩子）。 我在工作中使用了一个Haskell程序，它使用像text，xml-enumerator，attoparsec-text等库。我可以正常工作在我的Windows机器上，我的Ubuntu虚拟机在工作（32位），我的Ubuntu桌面（再次32位）和运行Ubuntu（64位）的EC2实例。
我们的客户正在运行CentOS 5.3,64位。 我不能为我的生活得到这个可执行文件正常运行。 我试图创build一个静态的可执行文件，
ghc --make myprog.hs -optl-static -optl-pthread 但是当我尝试在CentOS服务器上运行该可执行文件时，我收到一条错误消息：
openFile: invalid argument (Invalid argument)
我假设这与这里描述的错误有关。 我试过编译32位和64位Ubuntu，尝试静态和共享的构build，没有任何工作（虽然我偶尔会得到segfaults而不是上述错误信息）。 我可以尝试下载CentOS 5.3并为它创build一个虚拟机，但下载需要一段时间，我不确定哪个版本的GHC可以工作（我尝试在服务器上获得GHC 7，但是我跑了到一个libc的问题）。
在这一点上，我提出了一些可能的方法，但是我想尽可能地避免这些方法：
总而言之，在这些情况下，我真的希望我们有一个用于GHC的JVM后端。 我想我也可以试用LambdaVM。 但我很想听听社区的build议，在这里做什么。
这个简单的例子“适合我”：
$ cat A.hs main = print "yes" $ ghc -O2 --make -static -optc-static -optl-static A.hs -fvia-C -optl-pthread $ ldd A not a dynamic executable $ ./A "yes"
（在过去的几年里，我通过.cabal使用这个过程来为客户提供可执行文件）。
我认为最好的办法是提交错误，并使其正常工作。 IHG也可以为这样的工作提供资金，但是我相当确信，如果您尝试运送产品，GHC团队会认为这是高优先级。
它与CentOS中的旧glibc库有关。 您必须使用与CentOS上安装的相同版本的glibc进行编译。
我有完全一样的问题。 在arch（或ubuntu）上编译的Haskell可执行文件不能在CentOS上运行。 在我的情况下，虽然我很幸运，因为我们的管理员只是删除了CentOS并安装了Arch应用服务器。
我发现了这个问题。 看来Biohaskell页面的链接是准确的：这是加载iconv的问题。 这发生在调用openFile ，而不是调用openBinaryFile 。 由于xml-enumerator使用后者，它工作得很好。 改用其余的代码来使用openBinaryFile来代替（通过Data.Enumerator.Binary.enumFile ）让所有东西都起作用。
这对我的用例来说是一个很好的解决方法，但是这个错误依然存在。