Difference between revisions of "Web/Literature/Static linking"
From HaskellWiki
< Web | Literature
Tomjaguarpaw (talk | contribs) (Deleting page that hasn't been edited for over 10 years) |
m (Reverted edits by Tomjaguarpaw (talk) to last revision by Chrisdone) |
||
Line 1: | Line 1: | ||
+ | [[Category:Web|*]] | ||
+ | {{Web infobox}} | ||
+ | {{Template:Stub}} | ||
+ | '''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 <tt>-static | ||
+ | -optl-static</tt> to GHC will avoid problems with missing libraries on | ||
+ | the web server. | ||
+ | |||
+ | For example, this simple program, | ||
+ | |||
+ | <haskell> | ||
+ | import Database.SQLite | ||
+ | main = print "hey, test this" | ||
+ | </haskell> | ||
+ | |||
+ | when compiled as $ ghc A.hs --make is dynamically linked against: | ||
+ | |||
+ | <haskell> | ||
+ | $ 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 | ||
+ | </haskell> | ||
+ | |||
+ | Now, we can just pass some linker flags through to statically link this lot, | ||
+ | |||
+ | <haskell> | ||
+ | $ 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 | ||
+ | </haskell> | ||
+ | |||
+ | You could also use the [[Haskell Web Server]]. | ||
+ | |||
+ | '''Caveats:''' | ||
+ | |||
+ | * The <tt>-static</tt> 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 <tt>-lpthread</tt> after <tt>-lrt</tt> in the gargantuan linker invocation). This problem should disappear with GHC 6.8.3. | ||
+ | * Sometimes you will need to add <tt>extra-libraries</tt> fields to various libraries' <tt>.cabal</tt> files. This manifests as missing symbols. Note that many linkers are sensitive to the order of the <tt>-l</tt> arguments, so the order of libraries in this field matters. |
Revision as of 15:18, 6 February 2021
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.
Caveats:
- 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.