2012-05-10 17 views
15
  1. ¿Cómo se puede dejar caer dependencia dinámica en libgmp e ir de esto:estáticamente enlace GMP a una aplicación Haskell usando GHC (+ LLVM)

    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) 
    

    a esta (en la actualidad se desea):

    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) 
    

    de una manera limpia y portátil que solo funciona en todas las distribuciones de GNU/Linux (y no estropear con BSD (incluido OS X))?

  2. ¿Ve alguna otra dependencia que pueda causar problemas en la lista actualmente deseada como se indicó anteriormente cuando se distribuye un solo binario Haskell dirigido a múltiples distribuciones de GNU/Linux?


Notas:

+0

¿Cómo es su proceso de implementación? Específicamente, ¿qué impide que implemente libgmp junto con su aplicación? ¿Qué quiere decir con no estropear BSDs incluyendo OSX? No puede ejecutar el mismo binario tanto en OSX como en Linux. – asm

+0

@AndrewMyers Yo uso Cabal para las construcciones. Implementar libgmp? ¿Cómo? Quiero apoyar al menos Windows, Linux, OS X y FreeBSD. Si necesito crear una versión de biblioteca compartida/dinámica de libgmp para cada plataforma para implementarlo junto con mi aplicación, eso es demasiado trabajo. No estropear: una solución que funciona preferiblemente no solo en un solo sistema operativo; Estaba pensando en alguien que posiblemente sugiera usar algo como 'locate libgmp' y usar lo que pueda devolver en el momento del enlace y' locate' comportándose de manera diferente en diferentes sistemas operativos. (Sustituya 'locate' con cualquier otra herramienta aquí si lo desea). –

+0

Parece que está hablando de implementar un archivo binario, que deberá compilar para cada plataforma. Como debes compilarlo para cada plataforma, tienes que tener una versión de libgmp para cada plataforma de todos modos, así que puedes empacar esto con tu binario. ¿Me estoy perdiendo algo acerca de cómo planeas distribuir tu aplicación? – asm

Respuesta

15

Si pasa -optl-static -optl-pthread a GHC, enlazará estáticamente todas las dependencias de la biblioteca en tiempo de ejecución, incluido GMP. Establecer ld-options: -static -pthread en su archivo Cabal debería lograr lo mismo.

Eso significa que vinculará estáticamente en glibc también, pero eso probablemente no será un problema, aunque podría aumentar un poco el tamaño del binario. Usar una libc alternativa como musl o uClibc debería ayudar a contrarrestar eso, si es un problema para usted.

+2

¿Por qué se necesita '-pthread'? –

+1

No estoy seguro. La última vez que vinculé estáticamente un programa con GHC, obtuve errores relacionados con los símbolos pthread si no lo pasaba. Puede que ya no sea necesario. – ehird

+0

Acabo de vincular una aplicación lo más estáticamente posible. ** Windows ** y ** OS X **: 'libgmp' está compilado estáticamente. ** Linux **: '-static' para' ghc' y 'ld' es suficiente sin' -pthread'; 'libc' está vinculado estáticamente, pero advierte sobre la carga dinámica utilizada dentro de' libc'. ** FreeBSD **: siempre se queja de los símbolos 'pthread' ya sea que use' -pthread' o no. –

Cuestiones relacionadas