Web/Literature/Static linking: Difference between revisions
< 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.