如何在 eeePc 701 / Ubuntu Netbook Remix 1.6 (Lucid) 上构建 cabal-install
不是编程问题，但我第一次看到这样的问题。
UNR 1.6（基于Ubuntu 10.04）安装6.12.1版本的GHC。
因此，为了构建 cabal-install-0.8.2，我必须安装
libghc6-parsec、mtl、network 和 zlib 包。
然后，启动“sh ./bootstrap.sh”后，我得到：
正在检查已安装的软件包是否有 ghc-6.12.1...
parsec已经安装并且版本没问题。
网络已安装且版本正常。
Cabal已经安装并且版本没问题。
mtl已经安装并且版本没问题。
HTTP已经安装并且版本没问题。
zlib已经安装并且版本没问题
[1 of 1] 编译主程序（Setup.hs、Setup.o）
链接设置...
配置 cabal-install-0.8.2...
预处理 cabal-install-0.8.2 的可执行文件...
构建 cabal-install-0.8.2...
[ 1 of 40] 编译 Distribution.Client.BuildReports.Types ( Distribution/Client/BuildReports/Types.hs, dist/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Types.o )
[ 2 of 40] 编译 Distribution.Client.Utils ( Distribution/Client/Utils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Utils.o )
...关于未使用 addPackageExcludeConstraint 和 response 的两个警告。 ..
[39 of 40] 编译 Distribution.Client.Install ( Distribution/Client/Install.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Install.o )
[40 of 40] 编译 Main ( Main.hs, dist/build/cabal/cabal-tmp/Main.o )
链接 dist/build/cabal/cabal ...
collect2: ld 终止于信号 9 [Processus arrêté]
cabal-install bootstrap 期间出错:
构建 cabal-install 包失败
在链接和收集 2 之间（一分钟左右），我的硬盘驱动器的 LED 闪烁
就好像写入或读取了很多文件。
我不知道它是否相关，但这里是依赖项的版本
Cabal-1.8.0.2
HTTP-4000.0.6
mtl-1.1.0.2
网络-2.2.1.7
秒差距-2.1.0.1
zlib-0.5.2.0
Not a programming question, but the first time I see something like this.
UNR 1.6 (based on Ubuntu 10.04) installs the 6.12.1 version of GHC.
So, in order to build cabal-install-0.8.2, I have to install
the libghc6- packages of parsec, mtl, network and zlib.
Then, after launching 'sh ./bootstrap.sh', I get:
Checking installed packages for ghc-6.12.1...
parsec is already installed and the version is ok.
network is already installed and the version is ok.
Cabal is already installed and the version is ok.
mtl is already installed and the version is ok.
HTTP is already installed and the version is ok.
zlib is already installed and the version is ok.
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Configuring cabal-install-0.8.2...
Preprocessing executables for cabal-install-0.8.2...
Building cabal-install-0.8.2...
[ 1 of 40] Compiling Distribution.Client.BuildReports.Types ( Distribution/Client/BuildReports/Types.hs, dist/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Types.o )
[ 2 of 40] Compiling Distribution.Client.Utils ( Distribution/Client/Utils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Utils.o )
... two warnings about not used addPackageExcludeConstraint and response ...
[39 of 40] Compiling Distribution.Client.Install ( Distribution/Client/Install.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Install.o )
[40 of 40] Compiling Main ( Main.hs, dist/build/cabal/cabal-tmp/Main.o )
Linking dist/build/cabal/cabal ...
collect2: ld terminated with signal 9 [Processus arrêté]
Error during cabal-install bootstrap:
Building the cabal-install package failed
Between linking and collect2 (a minute or so), the LED of my hard drive twinkles
as if a lot of files are written or read.
I don't know if it's relevant but here are the versions of the dependencies
Cabal-1.8.0.2
HTTP-4000.0.6
mtl-1.1.0.2
network-2.2.1.7
parsec-2.1.0.1
zlib-0.5.2.0
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
发生的情况是内核正在终止 ld 链接器进程，因为它使用了太多内存。
ld使用如此多内存的原因是由于一种名为“split objs”的功能，该功能导致像libHSbase.a这样的标准库包含数十万个微小的小对象。.o文件。链接器未针对此用例进行优化，最终会使用大量内存。“split objs”功能旨在通过仅链接实际使用的标准库的位来使编译后的程序变得更小。它的工作原理是将每个已编译的 Haskell 模块拆分为每个函数的单独的
.o文件。因此，对于内存较少的系统（例如上网本）来说，这显然是一个问题。您链接的任何内容都可能发生这种情况，而不仅仅是
cabal。可以在关闭 splitobjs 功能的情况下从源代码构建 ghc。例如，Gentoo 对于 RAM 为 512Mb 或更少的机器自动执行此操作。因此，如果您想在上网本上可靠地使用 ghc，您可能需要 构建它来自源代码，没有 splitobjs。您可以在功能稍微强大的机器上构建 ghc，然后将其传输到您的上网本。将来，当我们在 Linux 上默认使用共享库时，这个问题就会消失。
What is happening is that the kernel is killing the
ldlinker process because it is using too much memory.The reason
ldis using so much memory is because of a feature called "split objs" which has the consequence that standard libraries likelibHSbase.acontain 10s of thousands of tiny little.ofiles. The linker is not optimised for this use-case and ends up using a lot of memory.The "split objs" feature is intended to make compiled programs much smaller by linking in only the bits of the standard libraries that are actually used. It works by splitting each compiled Haskell module into a separate
.ofile for each function.So this is obviously a problem for systems with less memory, like your netbook. It is likely to happen with anything you link, not just
cabal. It is possible to build ghc from source with the splitobjs feature turned off. For example, Gentoo does this automatically for machines with 512Mb of RAM or less. So if you want to use ghc reliably on your netbook you'll probably need to build it from source without splitobjs. You can build ghc on a slightly more powerful machine and then transfer it to your netbook.In future this problem will go away when we switch to using shared libraries by default on Linux.
我有同样的问题。我随时在 ghc-..ebuild 中添加 splitobjs=NO。然后我重建ghc，但cabal-install仍然无法通过ld。因为我的gentoo盒子没有交换分区。所以我用我的2G USB盘创建一个临时交换分区。然后我就可以构建 cabal-install 成功了。
我发现它会使用额外的 100M 交换空间，而我的 eeepc 有 512M 内存。所以我认为你可以使用1个100M以上空间的U盘。
只是：
mkswap /dev/sd* 交换 /dev/sd*
I have the same issue. I add splitobjs=NO at anytime in ghc-..ebuild. then I rebuild ghc, but cabal-install still can't pass ld. because my gentoo box has no swap partition. So I use my 2G usb disk to create one temporary swap partition. then I can build cabal-install success.
I found it will use extra 100M swap space and my eeepc has 512M memory. So I think you can use one usb disk that has more than 100M space.
just:
mkswap /dev/sd* swapon /dev/sd*
dd if=/dev/zero of=/swapfile bs=1024 count=2048k
mkswap /交换文件
交换/交换文件
dd if=/dev/zero of=/swapfile bs=1024 count=2048k
mkswap /swapfile
swapon /swapfile