2011/12/1 Irene Knapp
The typical trick to force GHC to statically link a C library is to give the full path to the .a of it as one of the object files in the GHC invocation that does the final linking. This means you don't need any -l or -L flags pertaining to that library. Some libraries are very particular about the order you list them in when doing this, but I don't really understand the issues there. You usually will also have to chase dependencies by hand and list them in the same fashion.
I recently tried using this method to create static binary; but I was not able to get it to work. I thought I would revive this old thread and see if anyone else has given it a shot. What I attempted was building a binary with only some C libraries statically linked, with this command line: # Build https://github.com/erudify/sssp on Ubunut 12.04 ghc -outputdir ./tmp -v --make -O2 sssp.hs -o sssp.ubuntu \ /usr/lib/x86_64-linux-gnu/libffi.a \ /usr/lib/x86_64-linux-gnu/libgmp.a \ /usr/lib/x86_64-linux-gnu/libz.a However, this really made no difference. Running `ldd' on the resulting binary reveals that libz and friends are still dynamically linked: ldd sssp.ubuntu linux-vdso.so.1 => (0x00007fff94253000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0ddfdbb000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0ddfb9e000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f0ddf92f000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f0ddf727000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0ddf42d000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0ddf224000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0ddf020000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0ddec63000) /lib64/ld-linux-x86-64.so.2 (0x00007f0ddffdb000) There is always -optl-static which, nowadays, results in a truly static executable; but it leads to a lot of warnings, too. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B