Differences between revisions 1 and 11 (spanning 10 versions)
Revision 1 as of 2015-05-19 01:24:50
Size: 1637
Editor: PaulWise
Comment: static linking page
Revision 11 as of 2015-05-19 21:08:58
Size: 3689
Editor: ?GregorHerrmann
Comment: remove duplicate word
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
In general Debian Policy [[https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static|allows]] static linking but they have various [[#downsides|reasons]]. In general Debian Policy [[https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static|allows]] static linking but it has various [[#downsides|downsides]].
Line 12: Line 12:
It requires rebuilding the world when the libraries change.  * It requires rebuilding the world when the libraries change.
 * It is harder to track than dynamic linking.
 * It prevents memory sharing between different executables using the same code.
 * It renders some security measure less effective (ASLR for example).
 * To comply with the DFSG and GNU GPL, we need to keep old source around.
 * Possible to ship incomplete libs. Eg. foo() depends on bar() but bar() not present at link time.
Line 14: Line 19:
It is harder to track than dynamic linking.

??
<<Anchor(upsides)>>
== Upsides ==
 * Code can be built non-fpic, which can be 5-20% faster due to register pressure, depending on arch. (Especially numerical code).
Line 37: Line 42:
=== OCaml ===

All OCaml libraries are statically linked into the final binary.

The release team have a [[https://release.debian.org/transitions/html/ocaml.html|transition]] that tracks OCaml rebuilds.
Line 39: Line 50:
?? The go tool from golang currently requires all libraries be available in source form and then builds everything into one binary. These source files in the -dev packages are the equivalent of the .a file.

When using gccgo-5 (go -gccgo), the Go runtime library is dynamically linked against an executable, however everything else is again linked "statically".

There is currently work ongoing by Michael Hudson-Doyle to support building shared go libraries. Support for dynamic linking (for amd64 only) will be in Go 1.5 which is due out in August 2015. Changes will be required to the Go packaging and dh-golang to support packaging Go packages as shared libraries.

=== FreePascal ===
The FreePascal Compiler (fpc) packages in Debian don't seem to use dynamic linking. See also [[http://wiki.freepascal.org/Lazarus/FPC_Libraries|here]].
Line 44: Line 62:
The Debian archive keeps around old sources referenced by the [[https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using|Built-Using]] header, marking them with the Extra-Source-Only header.
Line 45: Line 65:

For safety reasons, binaries should be linked dynamically to include hardening features e.g. ASLR. A user should be able to presume that binaries shipped by Debian are safe to use in front-facing (e.g. web services) scripts, etc.

Change debian-policy to discourage static linking?

Intro

In general Debian Policy allows static linking but it has various downsides.

This page aims to document the downsides and mitigations we have in place for those downsides as well as improving the situation in Debian around static linking.

Downsides

  • It requires rebuilding the world when the libraries change.
  • It is harder to track than dynamic linking.
  • It prevents memory sharing between different executables using the same code.
  • It renders some security measure less effective (ASLR for example).
  • To comply with the DFSG and GNU GPL, we need to keep old source around.
  • Possible to ship incomplete libs. Eg. foo() depends on bar() but bar() not present at link time.

Upsides

  • Code can be built non-fpic, which can be 5-20% faster due to register pressure, depending on arch. (Especially numerical code).

Affected

Various technology in Debian uses or is affected by static linking.

C libraries

C libraries support static linking and files are named *.a and can be unpacked with the ar tool from binutils.

Packages can declare they were built using code from other packages by using the Built-Using header and the Debian archive keeps around old sources, marking them with the Extra-Source-Only header.

Lintian detects binaries that have been statically linked.

Haskell

All Haskell libraries are statically linked into the final binary.

The release team have a transition that tracks Haskell rebuilds.

OCaml

All OCaml libraries are statically linked into the final binary.

The release team have a transition that tracks OCaml rebuilds.

Go

The go tool from golang currently requires all libraries be available in source form and then builds everything into one binary. These source files in the -dev packages are the equivalent of the .a file.

When using gccgo-5 (go -gccgo), the Go runtime library is dynamically linked against an executable, however everything else is again linked "statically".

There is currently work ongoing by Michael Hudson-Doyle to support building shared go libraries. Support for dynamic linking (for amd64 only) will be in Go 1.5 which is due out in August 2015. Changes will be required to the Go packaging and dh-golang to support packaging Go packages as shared libraries.

FreePascal

The ?FreePascal Compiler (fpc) packages in Debian don't seem to use dynamic linking. See also here.

Mitigation

The Debian archive keeps around old sources referenced by the Built-Using header, marking them with the Extra-Source-Only header.

Manual binNMUs can be done for packages that declare a Built-Using header.

For safety reasons, binaries should be linked dynamically to include hardening features e.g. ASLR. A user should be able to presume that binaries shipped by Debian are safe to use in front-facing (e.g. web services) scripts, etc.

Change debian-policy to discourage static linking?