< Web | Literature
This article is a stub. You can help by expanding it.
This article is out of date, it refers to GHC 6.8 and Database.SQLite. Please someone update it with a more recent example, if necessary.
Deploying statically linked applications
Linking your applications statically by giving the flags -static -optl-static to GHC will avoid problems with missing libraries on the web server.
For example, this simple program,
import Database.SQLite main = print "hey, test this"
when compiled as $ ghc A.hs --make is dynamically linked against:
$ ldd A A: Start End Type Open Ref GrpRef Name 0000000000000000 0000000000000000 exe 1 0 0 A 0000000041a85000 0000000041ee5000 rlib 0 1 0 /usr/local/lib/libsqlite3.so.9.0 0000000049b04000 0000000049f1d000 rlib 0 1 0 /usr/lib/libm.so.2.3 0000000042213000 000000004264f000 rlib 0 1 0 /usr/local/lib/libgmp.so.7.0 0000000047d0e000 00000000481e0000 rlib 0 1 0 /usr/lib/libc.so.42.0 0000000047900000 0000000047900000 rtld 0 1 0 /usr/libexec/ld.so
Now, we can just pass some linker flags through to statically link this lot,
$ ghc A.hs --make -optl-static -no-recomp $ ldd A ldd: A: not a dynamic executable $ file A A: ELF 64-bit LSB executable, AMD64, version 1, for OpenBSD, statically linked, not stripped
You could also use the Haskell Web Server.
- The -static flag in GHC 6.8.2 does not link the libraries in the correct order, resulting in a link failure (which you can hack around if you have to by shuffling -lpthread after -lrt in the gargantuan linker invocation). This problem should disappear with GHC 6.8.3.
- Sometimes you will need to add extra-libraries fields to various libraries' .cabal files. This manifests as missing symbols. Note that many linkers are sensitive to the order of the -l arguments, so the order of libraries in this field matters.