Haskell链接到Ubuntu上的动态库

Question

我有问题链接到我们编写的Haskell库。它在Ubuntu上出错，但不在Arch Linux上。我们得到在Ubuntu的错误是这样的：

/usr/bin/ld: warning: libHSdeepseq-1.3.0.0-ghc7.4.1.so, needed by /usr/lib/ghc/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.1.so, not found (try using -rpath or -rpath-link) /usr/lib/ghc/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.1.so: undefined reference to 'deepseqzm1zi3zi0zi0_ControlziDeepSeq_zdfNFDataArrayzuzdcrnf1_info'

这个问题似乎由事实libHScontainers-0.4.2.1-ghc7.4.1.so是不正确的链接为一个可以通过ldd输出看到的原因造成的： ldd /usr/lib/ghc/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.1.so linux-vdso.so.1 => (0x00007fffe95a2000) libHSdeepseq-1.3.0.0-ghc7.4.1.so => not found libHSbase-4.5.0.0-ghc7.4.1.so => not found libHSghc-prim-0.2.0.0-ghc7.4.1.so => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f89a5a59000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f89a569a000) /lib64/ld-linux-x86-64.so.2 (0x00007f89a5fd8000)

显然，依赖库无法找到。他们已安装。但是，如果我在Arch上也这样做： ldd /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/libHSdeepseq-1.3.0.2-ghc7.8.3.so linux-vdso.so.1 (0x00007fff09dfe000) libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007fb8d3e96000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fb8d3b91000) librt.so.1 => /usr/lib/librt.so.1 (0x00007fb8d3988000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fb8d3784000) libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fb8d357b000) libHSarray-0.5.0.0-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../array-0.5.0.0/libHSarray-0.5.0.0-ghc7.8.3.so (0x00007fb8d32e1000) libHSbase-4.7.0.1-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../base-4.7.0.1/libHSbase-4.7.0.1-ghc7.8.3.so (0x00007fb8d2967000) libHSinteger-gmp-0.5.1.0-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../integer-gmp-0.5.1.0/libHSinteger-gmp-0.5.1.0-ghc7.8.3.so (0x00007fb8d274c000) libHSghc-prim-0.3.1.0-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.so (0x00007fb8d24cf000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fb8d212c000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fb8d1f10000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007fb8d435f000)

找到了这些库。

建议我可以通过在应用程序中使用-rpath来解决此问题，我们尝试链接到Haskell库。但这意味着我们必须为每个Haskell包做这件事，这对我来说似乎是错误的。 我们还可以通过在/etc/ld.so.conf.d/ghc.conf中添加一行来解决此问题。但是这也必须针对每个包进行，并且不便于用户使用。

我有几个问题：

• 什么是解决这个问题的正确方法是什么？
• 为什么ghc-dynamic中的软件包不正确地链接？
• 为什么连接器能够找到libHScontainers-0.4.2.1-ghc7.4.1.so而不是libHSdeepseq-1.3.0.0-ghc7.4.1.so？

Answer 1

我强烈怀疑，这是因为安装了GHC Haskell的库有它们的依赖的位置（他们的ELF头的RPATH领域，你可以验证使用readelf -d）在$ORIGIN定义。当库X取决于库Ÿ，图书馆X可以指示库Ÿ应在相对于其自身位置的位置使用$ORIGIN找到。这由动态链接器支持，但静态链接器不支持。

（我猜测这里:)你的图书馆将确定其直接依赖的位置（在你的情况，我猜，这包括containers）在自己的RPATH，这是不是在条款方面的$ORIGIN。这就是为什么链接器可以找到这些，但不是它的传递依赖（再次，我猜，这包括deepseq在你的情况）。

那么为什么Arch Linux和Ubuntu的区别？ （进一步推测）这是因为与Arch Linux不同，Ubunbu的链接器默认使用--as-needed。你会发现，ghc会将你的库链接到所有的它的依赖关系（包括可传递的链接库），但是链接程序会省略一些依赖关系，因为它不直接依赖它们。你可以用--no-as-needed重新链接来验证。

请注意，静态链接器的这些错误确实不是错误，而是警告：它尝试解析符号，但它不能; ，但动态链接器将能够反正。所以你可以指示链接器忽略这些错误（--unresolved-symbols=ignore-all），一切都会好的。

我一直在为Cabal添加明确的支持，以生成用于C程序的Haskell库，并发现相同的问题。详情请见https://github.com/haskell/cabal/pull/2540#issuecomment-95984067。