2012-05-10 58 views
15
  1. Jak mogę spaść dynamiczną zależność od libgmp i iść z tym:statycznie łącza GMP do aplikacji Haskell użyciu 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) 
    

    to (obecnie pożądane):

    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) 
    

    w czysty i przenośny sposób, który działa tylko na wszystkich dystrybucjach GNU/Linux (i nie psuje się z BSD (w tym OS X))?

  2. Czy widzisz jakieś inne zależności, które mogą powodować problemy na aktualnie pożądanej liście, jak podano powyżej, podczas dystrybucji pojedynczego pliku binarnego Haskella, przeznaczonego do wielu dystrybucji GNU/Linux?


Uwagi:

+0

Jaki jest twój proces wdrażania? W szczególności, co powstrzymuje Cię przed wdrożeniem libgmp wraz z aplikacją? Co masz na myśli, nie psując się na BSD, w tym OSX? Nie można uruchomić tego samego pliku binarnego zarówno w systemie OSX, jak i Linux. – asm

+0

@AndrewMyers Używam Cabala do kompilacji. Wdróż libgmp? W jaki sposób? Chcę obsługiwać przynajmniej Windows, Linux, OS X i FreeBSD. Jeśli potrzebuję zbudować bibliotekę współużytkowaną/dynamiczną wersję libgmp dla każdej platformy, aby wdrożyć ją wraz z moją aplikacją, to po prostu za dużo pracy. Nie zepsuć: rozwiązanie, które najlepiej działa nie tylko na jednym systemie operacyjnym; myślał o kimś, kto sugeruje użycie czegoś takiego jak 'locate libgmp' i użyj tego co może powrócić w czasie łącza i' locate' zachowuje się inaczej na różnych systemach operacyjnych. (Zamień 'locate' na inne narzędzie, jeśli chcesz.) –

+0

Wygląda na to, że mówisz o wdrażaniu pliku binarnego, który musisz zbudować dla każdej platformy. Ponieważ musisz go zbudować dla każdej platformy, musisz mieć wersję libgmp dla każdej platformy, więc możesz po prostu spakować to z plikiem binarnym. Czy brakuje mi informacji o tym, jak zamierzasz dystrybuować swoją aplikację? – asm

Odpowiedz

15

Po przekazaniu -optl-static -optl-pthread do GHC nastąpi statyczne powiązanie wszystkich zależności bibliotek środowiska wykonawczego, w tym GMP. Ustawienie ld-options: -static -pthread w pliku Cabal powinno spowodować to samo.

To oznacza, że ​​będziesz statycznie linkować również w glibc, ale to prawdopodobnie nie będzie stanowiło problemu, chociaż może zwiększyć nieco rozmiar binarny. Używanie alternatywnej biblioteki libc, takiej jak musl lub uClibc, powinno pomóc w przeciwdziałaniu, jeśli jest to problem dla Ciebie.

+2

Dlaczego trzeba '-pthread'? –

+1

Nie jestem pewien. Kiedy ostatnio statycznie połączyłem program z GHC, otrzymałem błędy odnoszące się do symboli pthread, jeśli go nie zdałem. To może już nie być konieczne. – ehird

+0

Właśnie połączyłem aplikację tak statycznie, jak to możliwe. ** Windows ** i ** OS X **: 'libgmp' jest statycznie skompilowany. ** Linux **: '-static' dla' ghc' i 'ld' wystarcza bez' -pthread'; 'libc' jest statycznie połączone, ale ostrzega przed dynamicznym ładowaniem używanym wewnątrz' libc'. ** FreeBSD **: zawsze narzeka na symbole 'pthread' czy używam' -pthread', czy nie. –