使用GHC（+ LLVM）将GMP静态链接到Haskell应用程序 [英] Statically link GMP to an Haskell application using GHC (+ LLVM)

问题描述

1. 如何删除对 libgmp 的动态依赖关系，并从此处开始：
   
   

     linux-vdso.so.1 => （0x00007fffdccb1000）
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10（0x00007fb01afc1000）
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6（0x00007fb01acc7000）
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1（0x00007fb01aabe000）
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2（0x00007fb01a8ba000）
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0（0x00007fb01a69d000）
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6（0x00007fb01a2df000）
    /lib64/ld-linux-x86-64.so.2（0x00007fb01b249000）
     

   到此（目前需要）：
   
   

     linux- vdso.so.1 => （0x00007fffdccb1000）
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6（0x00007fb01acc7000）
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1（0x00007fb01aabe000）
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2（0x00007fb01a8ba000）
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0（0x00007fb01a69d000）
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6（0x00007fb01a2df000）
    /lib64/ld-linux-x86-64.so.2（0x00007fb01b249000）
     

   以干净和便携的方式，适用于所有GNU / Linux发行版（并且不会搞乱BSD（包括OS X））？




2. 在发布针对多个GNU / Linux发行版的单个Haskell二进制文件时，您是否发现可能会导致当前所需列表中存在问题的其他依赖关系？ / li>
   

---

注意：

• 我的应用程序是GPLv3，所以没有关于GMP的许可证违规问题


• 指定到 libgmp.a的路径不起作用（如何有选择地将某些系统库静态地链接到Haskell程序二进制文件中？）， libgmp 仍然列在 ld



解决方案

如果您将 -optl-static -optl-pthread 到GHC，它将静态链接所有运行时库依赖项，包括GMP。在你的Cabal文件中设置 ld-options：-static -pthread 应该完成同样的事情。

这意味着你在glibc中也会静态链接，但这可能不会成为问题，尽管它可能会增加二进制大小。使用替代libc，如 musl 或 uClibc 应该有助于抵消这种情况，如果这对您来说是个问题。

1. How can I drop dynamic dependency on libgmp and go from this:

   linux-vdso.so.1 =>  (0x00007fffdccb1000)
   libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb01afc1000)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb01acc7000)
   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb01aabe000)
   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb01a8ba000)
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb01a69d000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb01a2df000)
   /lib64/ld-linux-x86-64.so.2 (0x00007fb01b249000)
   

   to this (currently desired):

   linux-vdso.so.1 =>  (0x00007fffdccb1000)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb01acc7000)
   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb01aabe000)
   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb01a8ba000)
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb01a69d000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb01a2df000)
   /lib64/ld-linux-x86-64.so.2 (0x00007fb01b249000)
   

   in a clean and portable way that just works on all GNU/Linux distributions (and not messing up with BSDs (including OS X))?

2. Do you see any other dependencies that may cause problems in the currently desired list as given above when distributing a single Haskell binary targeting multiple GNU/Linux distributions?

---

Notes:

• my app is GPLv3 so no license violation issues arise regarding GMP
• Specifying a path to libgmp.a does not work ( How to selectively link certain system libraries statically into Haskell program binary? ), libgmp is still listed in the ldd output.

解决方案

If you pass -optl-static -optl-pthread to GHC, it'll statically link all the runtime library dependencies, including GMP. Setting ld-options: -static -pthread in your Cabal file should accomplish the same thing.

That means you'll statically link in glibc too, but that probably won't be a problem, although it might increase binary size quite a bit. Using an alternative libc like musl or uClibc should help counteract that, if it's a problem for you.

这篇关于使用GHC（+ LLVM）将GMP静态链接到Haskell应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！