GHC 6.12 和 MacPorts

发布于 2024-08-30 17:04:24 字数 2002 浏览 4 评论 0原文

我最近(从二进制安装程序)安装了 GHC 6.12 和 Haskell Platform 2010.1.0.1我的 Intel MacBook 运行 OS X 10.5.8,最初一切正常。 编辑:我必须从源代码安装 cabalalexhappy,但之后< /em>,一切似乎都运行良好。但是,我发现如果我使用cabal install来安装依赖于MacPorts库的软件包(例如cabal install --extra-lib-dirs= /opt/local/lib --extra-include-dirs=/opt/local/include gd),在 GHCi 中一切正常,但是如果我尝试编译,我会收到错误

Linking test ...
Undefined symbols:
  "_iconv_close", referenced from:
      _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o)
  "_iconv", referenced from:
      _hs_iconv in libHSbase-4.2.0.0.a(iconv.o)
  "_iconv_open", referenced from:
      _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

经过一些谷歌搜索后,我发现一个很长的 Haskell-cafe 线程讨论了这个问题。结果似乎是 MacPorts 安装了 libiconv 的更新版本,二进制接口与系统自带的版本略有不同。因此,如果您尝试链接任何 MacPorts 库,MacPorts libiconv 也会被链接;由于基础库是为了链接不同版本的 libiconv 而构建的,所以事情就崩溃了。我尝试过 设置 LD_LIBRARY_PATH 和 < code>DYLD_LIBRARY_PATH 并添加更多标志以尝试让它再次查看 /usr/lib例如 cabal install - -extra-lib-dirs=/opt/local/lib --extra-include-dirs=/opt/local/include --extra-lib-dirs=/usr/lib --extra-include-dirs=/usr/包括 gd),但都不起作用。卸载 MacPorts libiconv 并不是一个真正的选择,因为我安装了一堆依赖于它的端口——包括一些我希望 Haskell 链接到的端口,例如 gd2.

从我在网上看到的情况来看,结果似乎确实是“你被束缚了”:在使用 GHC 编译时无法链接到任何 MacPorts 库,而且似乎没有解决方案。然而,该线程是 2009 年底的,所以我认为有人可能有解决方案、解决方法、可笑的黑客……任何东西,真的。那么:有人知道如何让 GHC 6.12 在链接到 MacPorts 库的同时链接到系统 libiconv 吗?或者,如果做不到这一点,有一种使链接不会中断的方法 以其他聪明的方式?

I recently installed (from the binary installers) GHC 6.12 and the Haskell Platform 2010.1.0.1 on my Intel MacBook running OS X 10.5.8, and initially, everything worked fine. Edit: I had to install cabal, alex, and happy from source, but after that, everything did seem to work fine. However, I discovered that if I use cabal install to install a package which depends on a MacPorts library (e.g., cabal install --extra-lib-dirs=/opt/local/lib --extra-include-dirs=/opt/local/include gd), things work fine in GHCi, but if I try to compile, I get the error

Linking test ...
Undefined symbols:
  "_iconv_close", referenced from:
      _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o)
  "_iconv", referenced from:
      _hs_iconv in libHSbase-4.2.0.0.a(iconv.o)
  "_iconv_open", referenced from:
      _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

After some Googling, I found a long Haskell-cafe thread discussing this problem. The upshot seems to be that MacPorts installs an updated version of libiconv, and the binary interface is slightly different from the version included with the system. Consequently, if you try to link with any MacPorts library, the MacPorts libiconv gets linked in too; and since the base library was built to link against a different version of libiconv, things break. I've tried setting LD_LIBRARY_PATH and DYLD_LIBRARY_PATH and adding more flags to try to get it to look at /usr/lib again (e.g. cabal install --extra-lib-dirs=/opt/local/lib --extra-include-dirs=/opt/local/include --extra-lib-dirs=/usr/lib --extra-include-dirs=/usr/include gd), but neither worked. Uninstalling the MacPorts libiconv isn't really an option, since I have a bunch of ports installed which depend on it---including some ports I want Haskell to link to, like gd2.

From what I've seen online, the upshot really seems to be "you're boned": you cannot link against any MacPorts library while compiling with GHC, and there doesn't seem to be a solution. However, that thread was from the end of 2009, so I figure there's a chance that someone has a solution, workaround, ridiculous hack… anything, really. So: does anybody know how to get GHC 6.12 to link against the system libiconv at the same time as it links to libraries from MacPorts? Or, failing that, a way to make linking not break in some other clever way?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

风柔一江水 2024-09-06 17:04:24

当我安装 haskell-platform-2010.1.0.1-i386 并尝试编译 haskell 程序时,我在 MacOSX 10.5.8 上遇到了同样的错误。我的解决方案是在编译程序时向 ghc 添加选项“-L/usr/lib”。我相信这设法让链接器首先搜索 /usr/lib 中的 iconv 库,这为我解决了问题。

I was getting the same error on MacOSX 10.5.8 when I installed haskell-platform-2010.1.0.1-i386 and attempted to compile a haskell program. The solution for me was to add the option "-L/usr/lib" to ghc when compiling the program. I believe this managed to get the linker to first search /usr/lib for the iconv library which resolved the problem for me.

薯片软お妹 2024-09-06 17:04:24

我通过卸载 MacPorts 解决了我的问题。您可能只需卸载 MacPorts 版本的 libiconv 以及任何依赖它的库就可以逃脱惩罚。

I made my problems go away by uninstalling MacPorts. You could probably get away with just uninstalling the MacPorts version of libiconv and any library that depends on it.

属性 2024-09-06 17:04:24

我有点羞于承认这一点,但我已经通过如下咒语取得了一些成功:

LIBRARY_PATH=/usr/lib:/opt/local/lib cabal install --ghc-option="-L/usr/lib" SDL-gfx

I'm somewhat ashamed to admit this, but I've had some success with incantations like the following:

LIBRARY_PATH=/usr/lib:/opt/local/lib cabal install --ghc-option="-L/usr/lib" SDL-gfx
一个人的旅程 2024-09-06 17:04:24

我通过以下方式修复:

stack build --ghc-options "-L/usr/lib"

I fixed by :

stack build --ghc-options "-L/usr/lib"
屌丝范 2024-09-06 17:04:24

这很奇怪: afaik Platform 2010.1.0.1 不适用于 OS X 10.5 .8,这已经被包括我在内的几个人报告和验证,更有趣的是 - 你的

This is weird: afaik Platform 2010.1.0.1 does not work on OS X 10.5.8, this has been reported and verified by several people including myself, and more interestingly - by you!

自此以后,行同陌路 2024-09-06 17:04:24

也许这可能会更好
cabal 配置 --extra-lib-dir=/usr/lib
它确实解决了 OSX Mountain Lion 上的问题

Perhaps this may be better
cabal configure --extra-lib-dir=/usr/lib
It does resolve the issue on OSX Mountain Lion

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文